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1. Introduction 



1.1 Purpose 

Zendit offers services to enhance online personal privacy. Aditi has proposed to build a system 
that will enable users to encrypt and decrypt online messages, manage keys, manage the 
storage of users' personal information and manage the health and welfare of the entire system. 

This document provides an overview of the high-level design of the entire system. 

1.2 Scope 

The document would provide an insight into the implementation of the pages in the web site and 
the SurfBoard components. This document would also provide details regarding the interaction 
between the SurfBoard and the web site for data requests. 

1.3 Target audience 

This document is intended for the engineers responsible for developing and testing the Zendit 
system and the concerned Zendit system administrators. 

1 .4 Organization 

The design has been explained under three main sections: 

1 . The Zendit Web Site Design 

2. The SurfBoard Design 

3. The Database Design 

The other details that are covered in the document are 

a. Implementation of the hashing algorithm 

b. Registration and Key confirmation process 

c. Security on the pages. 



1.5 Software for implementation 

> ASP pages will be used on the web site to process all server requests. 

> SQL Server 7.0 will be used as the database server. 

> The SurfBoard components would be implemented as COM objects using ATL 

> The wrapper for OpenLib will be built using C/C++ 
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2. Database Design 



This section presents the details of the database design and gives the description of all the tables 
in the system. 

Table Name: tbIRegisteredUsers 
Table Description: 

This table would contain all the personal information about the user and certain other information 
related to the Zendit activities. 



>»/'' , t \ -^. ^v '""4'/-*, • , • 

Fma mm® ' \ - n*M Type, ; ngfc* f Mj^p$im}0<m ' ^ ■ 



LUyllllU 


Vaicnar 


on 


1 s\/"itrt 1/4 /Lilian V"\\ / Ihfi i lOAr 

Login la given oy xne user. 
The login Id would be unique 
for each user. 


Password 


varchar 


20 


Password given by the user. 


PrimaryEmaillD 


varchar 


250 


This is the email ID that 

WUUlU U6 USCU Jul all 

communications between 
Zendit system and the user. 


FirstName 


varchar 


100 


First name of the user. 


LastName 


varchar 


100 


Last name of the user. 


DateOfRegistration 


datetime 


8 


Date on which the user 
registers with Zendit system. 


Addressl 


varchar 


300 


Address of the user. 


Address2 


varchar 


300 


Address of the user. 


City 


Varchar 


50 


Name of the City 


State 


Varchar 


50 


Name of the State 
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Country 


Varchar 


50 


Name of the Country 


ZipCode 


Varchar 


50 


The zip code of the user 


ResidencePhone 


varchar 


25 


Residence phone number. 


OfficePhone 


varchar 


25 


Office phone number. 


Mobile 


varchar 


25 


Mobile phone number. 


Fax 


varchar 


25 


Fax number. 


ConfirmationFlag 


int 


4 


A flag indicating whether the 
user has confirmed the 
registration or not. The flag 
is set to "True" on 
confirmation of registration. 


DateOfConfirmation 


datetime 


8 


Date on which the user 
confirms the registration. 


NewMailStatus 


int 


2 


A flag indicating whether the 
user has any new mails. It is 
set to "True", if any new mail 
is received by the user and 
is set to "False", if any of the 
mails (new or old) is read by 
the user. 


LastLoginDate 


datetime 


8 


The date on which the user 
last logged into Zendit 
system. 


TotalSpaceAlloted 


float 


8 


Indicates the total free hard 
disk space given to the user 
by the Zendit server. 
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FreeSpaceLeft 



ListOfEmaillD 



float 



varchar 



2520 



Indicates the total unused 
hard disk space left for the 
user. 



Contains a string of email 
IDs (those in the certificates 
associated with the user's 
login ID) separated by 
commas. 



_L 



Table Name: tbIRegistrationConfirmation 
Table Description: 

This table would contain confirmation details for every successful registration. 



ConfirmationID 


varchar 


20 


Confirmation ID (for 
registration) sent to the user. 


LoginID 


varchar 


20 


Login ID of the user. 


DateOfRegistration 


datetime 


8 


Date on which the user 
registers with Zendit system. 


iMailSent 


Bit 


1 


Shows status of 
Confirmation Mail (0 if mail 
not sent and 1 otherwise) 
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Table Name: tbiNonConfirmedCerts 
Table Description: 

This table would contain non-confirmed certificates. 



EmaillD 


varchar 


250 


Email ID specified in the 
certificate. 


Key ID 


varchar 


17 


Key ID specified in the 
certificate. 


1 NCll 1 IC 


VCII Ol ICll 




Namp ^rifVLifipri in thfi 

) 1CIII 1 0 OUV/W 1 I^U III LI lv 

certificate. 


Certificate 


text 


16 


The digital certificate- 


MailSystem 


varchar 


50 


Mail system specified in the 
email ID field of the 
Certificate. 


InsertedbyZend 


int 


4 


A flag indicating whether the 
certificate was inserted by 
Zendit system. If so, flag is 
set to "True". 


vAlgo 


Varchar 


250 


The Algorithm used for 

frpfitinn thp Kpv nair 

l/l C7CILII IVj lilt r\vjf |k/QII 


vLength 


Varchar 


250 


The length of the key 
generated 


vType 


Varchar 


250 


The Key Type which is 
stored. (As of now only 
Public keys are stored in this 
table) 


dtCreate 


Datetime 


8 


Date of Key Creation 
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dtExpiry 


Datetime 


3 


Date of kev Exoirv 


MailSent 


int 


4 


A flag indicating whether the 








confirmation mail has been 








sent to the user. If the mail is 








sent successfully then the 








flag is set to "True" else it is 








set to "False 1 '. 



Table Name: tbIKeyConfirmation 
Table Description: 

This table is an intermediate table that holds the login ID - key ID relation till the user confirms the 
key pair. 




ConfirmationID 


varchar 


20 


Confirmation ID (for using 
the key Id) sent to the user. 


LoginID 


varchar 


20 


Login ID of the user. 


KeylD 


varchar 


17 


Key ID as in the certificate. 


DateOfCreation 


datetime 


8 


Date on which the certificate 
was created. 


EmaillD 


varchar 


250 


EmaillD associated with the 
key 


MailSent 


int 


4 


Flag which tells if the mail 
has been sent. (-1 for no) 
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Table Name: tbIConfirmedCerts 
Table Description: 

This table contains all the certificates associated with a login ID. 




LoginID 


varchar 


20 


Login ID of the user. 


EmaillD 


varchar 


250 


Email ID as in the certificate. 


Name 


varchar 


250 


Name as in the certificate. 


KeylD 


varchar 


17 


Key ID as in the certificate. 


MailSystem 


varchar 


50 


Mail system specified in the 
email ID field of the 
certificate. 


Certificate 


text 


16 


The digital certificate of the 
user. 


N u m be rOfM a i 1 sZe n d 


int 


4 


The number of mails zent by 
the user using the email ID. 


vAlgo 


Varchar 


250 


The Algorithm used for 
creating the Key pair 


vLength 


Varchar 


250 


The length of the key 
generated 


vType 


Varchar 


250 


The Key Type which is 
stored. (As of now only 
Public keys are stored in this 
table) 


dtCreate 


Datetime 


8 


Date of Key Creation 


dtExpiry 


Datetime 


8 


Date of key Expiry 
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Table Name: tblBadCerts 
Table Description: 

This table would have all the certificates that have been: 

> Moved from the table tbIConfirmedCerts (tbIBadCerts.Flag = Replaced) 

> Moved from the table tbINonConfirmedCerts (tbIBadCerts.Flag = Deleted) 



EmaillD 


varchar 


250 


Email ID as in the certificate. 


KeylD 


varchar 


17 


Key ID as in the certificate. 


Name 


varchar 


250 


Name as in the certificate. 


Flag 


int 


4 


The flag Indicates whether 
the certificate was 'Replaced' 
or 'Deleted 1 . 


Certificate 


text 


16 


The digital certificate. 


Table Name: tbiKeyUpload 
Table Description: 

This table would contain all the locks and keys uploaded by the user. 




LoginID 


varchar 


20 


Login ID of the user. 


EmaillD 


varchar 


250 


Email ID as in the lock and 
key uploaded by the user. 


KeylD 


varchar 


17 


Key ID as in the lock and key 
uploaded by the user. 


Name 


varchar 


250 


Name as in the lock and key 
uploaded by the user. 
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'Field Name 



44m 

Fi«f€t Type 



Length mm Description 



FileBlob 


text 


16 


lock and key uploaded by 
the user stored in blob 
format. 


DateOfUpload 


datetime 


8 


Date on which the user 
uploaded the lock and key. 



Table Name: tbIFileUpload 
Table Description: 

This table would contain ail the information about the files being uploaded by the user onto the 
Zendit server. 




IFileListID 


Int 




List ID of File 


LoginID 


varchar 


20 


Login ID of the user. 


NameOfFile 


varchar 


800 


Name of the file uploaded by 
the user. 


FileSize 


float 


8 


Size of the file uploaded by 
the user. 


DateOfUpload 


datetime 


8 


Date on which the user 
uploaded the file. 


FilePath 


varchar 


200 


Path (the entire network 
path) to the file where the 
user uploads in the Zendit 
server. 


ContentType 


Varchar 


500 





Note:- This Feature has been moved to later version 
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Table Name: tbIUserProfile 
Table Description: 

This table would contain all the personal information of user that would be shared with other 
users. 



LoainID 


Vdl UI Idl 


on 


Login iu oTtne user. 


ProfileString 


varchar 


5000 


The user would like to share 
some of his/her personal 
information (first name, last 
name, phone number etc.) 
with the other users. 
This field would contain the 
respective column names (of 
tbIRegisteredUsers table) 
separated by commas as a 
single string. 



Table Name: tbIAdminSettings 
Table Description: 

This table would contain all the admin settings for both the web site and SurfBoard set by an 
administrator. 



Key 


varchar 


20 


Key name 


KeyDesc 


varchar 


200 


Key description 


Value 


varchar 


200 


Key value 



The administrator is expected to update settings such as; 
Example: 

1) KeylD = iMaxCerts 

KeyDescription = Maximum certificates per user 
Value = 10 



2) KeylD = iTimelnactive 

KeyDescription = Time limit for inactivity 
Value = 60 
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Table Name: tbIFeedback 
Table Description: 

This table would contain the feedback information given by any registered or unregistered user 
and the details of reply sent for each feedback. 




IFeedListID 


Int 


4 


List Id of feedback from user 


EmaillD 


varchar 


80 


Email ID of the user who 
sent the feedback. 


DateOfReceive 


datetime 


8 


Date on which feedback was 
sent to Zendit. 


Feedback 


varchar 


800 


Feedback message. 


Replied 


int 


4 


A flag indicating whether the 
feedback has been replied to 
or not. This flag is set to "Y", 
if reply is sent to the 
feedback, else it is set to "N". 


DateOfReply 


datetime 


8 


Date on which reply was 
sent. 


Remarks 


varchar 


800 


The reply content. 



Table Name: tbITemplate 
Table Description: 

This table stores the templates and its version information, which is sent to surfboard at time of 
logging in 




iTemplateVer 


Int 


4 


Template version number 


vTemplate 


text 


16 


Encrypted Template 


vPassword 


varchar 


20 


Password to decrypt the 
Template 
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DdateOfUpdate 


datetime 


8 


Date of Creation of Template 



Table Name: tbISendTemplate 
Table Description: 

This table stores the Send templates for each of the mail system for both frame and non-frame 
based pages. 




ISendTempID 


Int 


4 


Id of the send template 


cMailSystem 


Varchar 


50 


Indicating the mail system, 
eg: Hotmail, Yahoo. 


IFrameType 


Int 


4 


Indicates If the page is 
frame, non frame or iframe 
based 


CToName 


Varchar 


50 


HTML field name given to 
the "TO" field in template 
used by the mail system. 


cCcName 


Varchar 


50 


HTML field name given to 
the "Cc" field in template 
used by the mail system. 


cBccName 


Varchar 


50 


HTML field name given to 
the "Bcc" field in template 
used by the mail system. 


cPlainText 


Varchar 


50 


HTML field name given to 
the "Message" field in (plain 
text) template used by the 
mail system. 


cFormatText 


Varchar 


50 


HTML field name given to 
the "Message" field in 
(formatted text) template 
used by the mail system. 
Ex: Field name given to the 
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Scriptlet used by the Yahoo 
mail system. 


CFormName 


Varchar 


50 


Name of the form containing 
all the information, buttons 
and message body 


cFrameURL 


Varchar 


300 


URL for Compose, Reply, 
Forward or Read frames 
wnen its a frame based 
page 


cMainURL 


Varchar 


300 


URL for the Page itself 


cDescription 

— 


varchar 


300 


A brief description about the 
template 



tbICiickTemplate 



Table Name: 
Table Description: 

pages. 6SS the dlfferent k,nd of submit buttons on the mailsystem 




iCIickTempID 



iSendTempID 



iPartID 



vElementType 



Int 



Int 



smalllnt 



varchar 



Id of the click template 



Id of the send template for 
which the click template is 
being added 



The Page element for whom 
the template is being added 



255 



Element Type 
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vAttributeName 


varchar 


255 


Name of the Element 


vAttributeValue 


varchar 


255 


Value of that particular 
Attribute 



Note:- The typical records for this table are listed as below 



iCIickTempID 
iSendTempID 
iPartID 

vElementType 

vAttributeName 

vAttributeValue 



4 
2 

1 

Input 

type 

button 



Table Name: tbIReadTemplate 
Table Description: 

This table stores the Read templates for each of the mail system for both frame and non-frame 
based pages. Using this we can access the compose mail system pages. 



«cl Name 



iReadTempID 


Int 


4 


Id of the read template 


cMailSystem 


varchar 


50 


Name of the mail system 


iFrameType 


Int 


4 


Type of Frame used (frame, 
non frame or iframe based 


cHeaderStart 


varchar 


150 


The start location in the 
source from which the 
sender information is 
extracted 


cHeaderEnd 


varchar 


150 


End of the header 


cSenderStart 


varchar 


150 


The start location in the 
source at which the sender 
information is embedded 
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cSenderEnd 


varchar 


150 


End of sender tag 


CTokenBegin 


varchar 


150 


The start location in the 
source at which the email id 
of the sender is embedded 


cTokenEnd 


varchar 


150 


The tag at which token ends 


cFrameURL 


varchar 


300 


URL of the frame (if it's a 
frame based paae) 


cMainURL 


varchar 


300 


URL of the page 


cDescription 


varchar 


300 


Description of the template 



Note: tbIReadTemplate is not used now for Dzending operation during signature verification. 
Instead it is done on the basis of Key ID. 

Table Name: tbITempKeyPairPool 

Thb taW?Sffrea pool of interim lock and keys generated by Zendit system. This is used for 
asinine ^temporary keys to new Email IDs. This table is populated by runn.ng a scr.pt in adm.n 

pages. 



cKeyPairBlob 


text 


16 


A blob (Binary large object) 
containing the key pair 


CPublicKeyBlob 


text 


16 


A blob (Binary large object) 
containing the public key of 
the key pair 


cKeylD 


varchar 


17 


A unique id of the key 


iFlgUsed 


int 


4 

■ 


A flag telling the system 
whether the key has been 
used (1 for used and 0 
otherwise) 
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Table Name: tblTempKeyConfirmation 
Table Description: 

This table contains the interim keys and related info for all the interim keys which are taken out of 
tbltempkeypairpool and are not yet confirmed. It also has the confirmation IDs for the users who 
have done quick registration. 



cEmaillD 


varchar 


250 


Email id associated with the 


cConfirmationlD 


varchar 




Onnfirmatinri in ^pni thp 

WVII If II 1 1 laUUI 1 IL-r ddll IV MIC 

target user 


cKeylD 


varchar 


17 


A unique Key ID 


iMailSent 


int 


4 


A flag depicting the success 
of Confirmation mail sent to 
the user. (0 if fail and 1 
otherwise) 


cSenderEmaillD 


varchar 


2500 


Email id of the sender who 
requested the temp key 


cLoginID 


varchar 


20 


Login id of the sender 


dtCreate 


datetime 


8 


Date of creation of temp key 



Table Name: tbIConfirmedTempKeys 
Table Description: 

This table contains the Confirmed interim keys and related info 



cLoginID 


varchar 


20 


Login ID of the user 


cEmaillD 


varchar 


250 


Email id associated with the 
temporary key 
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cKeyPairBlob 


text 


16 


The Key pair blob (Private 
key + public key) 


cKeylD 


varchar 


17 


A unique Key ID 


Table Name: tbIDPL 
Table Description: 

This table contains the names and info of persons on US federal government's denied p 
list. 




iListID 


int 


4 


Login ID of the user 


cName 


varchar 


250 


Full name of the person 


iFlag 


smallint 


2 


Flag indicating whether it's a 
person or a company's name 
(1 for person and 2 for 
company) 


cAddressI 


varchar 


250 


Address of the 
person/company 


cAddress2 


varchar 


250 


Address of the 
person/company 


cAddress3 


varchar 


250 


Address of the 
person/company 


cCity 


varchar 


250 


City of person/company 


estate 


varchar 


250 


State of person/company 


cCountry 


varchar 


250 


Country of person/company 
(required) 


cZip 


varchar 


50 


Zip code of person/company 


cEffectiveDate 


varchar 


250 


Restrictions applicable from 
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date(required) 


cExpirationDate 


varchar 


250 


The date when restrictions 
expire(required) 


cFRC 


varchar 


250 


The FRC issued 


CFRC_Date 


varchar 


250 


Date of issuance of FRC 



Table Name: tbIListLoginlDs 
Table Description: 

This table contains the Login Ids and corresponding unique List ids of registered users 






iListID 


int 


4 


A unique id generated for 










each user 




cLoginID 


varchar 


20 


Login id of the user 




dtLastAccessed 


datetime 


8 


Date when user last 










accessed the system 













Table Name: tbIListEmaillDs 
Table Description: 

This table contains the EmaillDs and corresponding Keys of registered users 



iListID 


int 


4 


A unique id generated for 








each Email address 


cEmaillD 


varchar 


250 


Email id 


cName 


varchar 


250 


Name of the user associated 
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cKeylD 



varchar 



17 



ID of the key associated with 
the email id 



Table Name: tbILoginEmaiilDs 
Table Description: 

This table contains the Email IDs of registered users. 



4=5;:. 




cLoginID 


varchar 


20 


Login Id of the user 


cEmaiilD 


varchar 


250 


Email ID associated with the 
user 


iFlag 


int 


4 


A flag determining whether 
the email address has an 
associated public lock or 
zend generated lock and key 


Table Name : tbl MailContent 
Table Description: 

This table contains the mail contents that are sent to the user for different scenarios. 




field Type ■ •; :it p-lmm:i¥m t>esc^^0i>^ 


iContentID 


int 


4 


A unique id for the mail 
content 


cMailFor 


varchar 


250 


Purpose of the mail 


cSubject 


varchar 


250 


Content of mail subject 


cMailContent 


varchar 


5000 


Content of maii body 


cMailDesc | 


varchar 


500 


Brief Description about the 
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Field Hmm Field Tvoe 


v -&'': Lenath 








^^^^^^^^^^^ 














mail 



Table Name: tbIMailsZent 
Table Description: 

This table keeps track of the number of mails zent to each mail system everyday 




cMailSystem 



dtMailZent 



iMailsZent 



varchar 



datetime 



int 



50 



Name of the mail system 



Date of zending mails 



Number of mails zent on that 
particular day to that 
particular system 



Table Name: tbIMailsZentLogin 
Table Description: 

This table keeps track of the number of mails zent by each user. 




cLoginID 


varchar 


20 


Login id of the user 


iMailsZent 


int 


4 


Number of mails zent by the 








user 



Table Name: tbIServerMap 
Table Description: 

This table Maps Servers names to unique Hash IDs. 




iHashID 



int 



Hash id to be mapped to 
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cServerName 



varchar 



100 



SQL Server Name 



Table Name: tbISurfBoardDownload 
Table Description: 

This table shows number of surfboard downloads for a particular day 




iDownloadCount 


int 


4 


Number of downloads for a 
particular day 


DateOfDownload 


datetime 


8 


Date of download recording 



Table Name: tbILoginStatus 
Table Description: 

This table tracks the user's login status once he is logged in 



cLoginID 


Varchar 


20 


Login Id of the user 


cStatusHash 


Varchar 


50 


A hash of session id and 
time stamp 


iSourceFlag 


int 


4 


A flag denoting whether the 
user logged from web or 
surfboard 


dtLastAccessed 


Datetime 


8 


The timestamp of the last 
user interaction with the 
server 
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Table Name: tbIReqPwdConf 
Table Description: 

This table contains the Confirmation IDs for those who have requested for password as they had 
forgotten it. 





cLoginID 


Varchar 


20 


Login Id of the user 




cEmaiilD 


Varchar 


250 


Primary Email Address of 
the user 




cConfID 


Varchar 


20 


Confirmation ID 




iMailSent 


Int 


4 


The flag that indicates 
whether the mail is sent or 
not. 














dtDate 


Datetime 


8 


Date on which the request is 
made 



Table Name: tbIHelpMapping 
Table Description: 

This table contains the mapping between the Mapping ID and the corresponding help page. 











cID 


Varchar 


15 


Mapping ID 


cPageName 


Varchar 


100 


The corresponding help 








page. 
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3. Zendit System Design 

The diagram depicts the Zendit architecture as proposed. 

Zendit Environment 



Rig 

Client 





internet 








lis By Ha HE 



Shadow SQL key SQL HS RIs Server 



3.1 Hashing implementation 

The hashing algorithm is applied to ensure that data is spread evenly across different SQL Server 
machines. The maximum number of machines is assumed to be 100. A mapping between a hash 
ID and SQL Server name is maintained. 

When a user registers with Zendit, the login ID is passed as a parameter to the hashing function. 
After hashing, a hash ID is generated which would be a number between 1 and 100. Depending 
on the hash ID generated, the user data is moved to the SQL Server that is mapped with that ID. 

From there on, hashing is performed on the login IDs to identify the SQL Server on which the 
user data is available. 

The hashing would be performed on email IDs also. 

3.2 Confirmation process 

Confirmation process could be classified as 

1 . Registration confirmation 

2. Certificate confirmation 
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3.2,1 Registration confirmation 

When the user registers successfully, a mail is sent to the primary email ID of the user. The mail 
would contain a confirmation ID that the user is required to submit at the website. 

A record is inserted into the tbIRegistrationConfirmation table with the login ID, the confirmation 
ID and date of registration. The user record in the tbIRegisteredUsers is marked as non- 
confirmed. 

When the user submits the confirmation ID, the tbIRegistrationConfirmation is queried for a record 
with matching login ID and confirmation ID. If found, the record in the tbIRegisteredUsers table is 
marked as confirmed and the corresponding record in the tbIRegistrationConfirmation table is 
deleted. 



3.2.2 Certificate confirmation 

When a newly created certificate is sent to the Zendit server along with an email ID, the following 
scenarios are handled: 

Key for an email ID does not exist 

A record is inserted into the tbINonConfirmedCerts table with the login ID, confirmation ID, key ID 
and other relevant data. 

A mail will be sent to the email ID associated with the key ID. The mail would contain a 
confirmation ID. The record is marked as 'mail sent' in the tbINonConfirmedCerts table once the 
mail is sent. 

A record is inserted into the tbIKeyConfirmation table with the login ID and key ID values along 
with other relevant information. 

Once the user submits the confirmation ID at the Zendit server (this process is done through the 
web site), the login ID and key ID combination is searched for in the tbIKeyConfirmation table. If 
found, record from the tbINonConfirmedCerts with this combination is moved to (Inserted) the 
tbiConfirmedCerts table and is deleted from the tbINonConfirmedCerts. The record in the 
tbIKeyConfirmation is also deleted. 

Key for an email ID that exists in the Zendit Server (tbiConfirmedCerts 1 ) 

If the key is for the same Login ID, a message would be displayed to the user informing about he 
key for the email ID already existing in the Zendit Server, with an option to replace it. 
If the user chooses to replace, the new key-email ID information is inserted into the 
tbiConfirmedCerts table and the older certificate will be moved to tbIBadCerts. 

If the key is associated with different Login ID, a message would be displayed that the Email 
address is associated with another login ID and cannot be published. 
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3.3 Security 



3.3.1 Security on Pages 

The pages that process SurfBoard requests would check to see if the referrer URL is 'NULL or 
the domain of the referrer URL would be the Zendit domain. As soon as the user logs in the 
Zendit system, the session id will be hashed and stored in tbiStatusHash. This statushash would 
be passed as parameters to all the interface pages that will validate with the database. 

The pages on the web site that act as an interface for user activity in the site, the identity of the 
user logged in would be maintained in a session based cookie. For all requests that require the 
user to be logged in, the pages would check the cookie to find out if the user has logged in. 
These pages also would look for the referrer URL to check if the requests are being made from 
the Zendit domain itself. Also when the user logs in the web vault, the session id will be hashed 
and stored in tbiStatusHash. This status hash will be stored in a cookie and the value of this 
cookie will be validated with that in the database. 

3.3.2 Database Security 

The user password is to be hashed using a hashing algorithm and stored in the database. This is 
to prevent unauthorized people accessing the password from the database. This prevents any 
security hazard for the users, as any person having access to the password in the database will 
be able to retrieve any personal information and more importantly execute any privileged task 
such as deleting the user's backed up key pairs or invalidating the credentials of the user by 
changing the user's primary email address. Thus the user password is hashed and the password 
hash is stored in the database. 

Note: For further details, please refer to the User Authentication and Login Status document 
attached under the section 3.4 



3.4 User authentication and login status 

The way the user is authenticated and method with which the user login status is maintained at 
the server is explained in the attached document. This is to ensure that no other person 
impersonates the user. The design of this process and the issues involved are discussed in the 
attached document. 



"User Authentication 
And Login Status.doc" 



3.5 Denied Persons List 

The US federal government restricts the export of security related software like Zendit to certain 
countries. Also, a list of persons that is maintained by the federal government are to be denied 
the services of the Zendit system. The implementation details and the issues involved are 
discussed in the attached document. 
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3.6 Zend generated lock and key 

When the user tries to send an encrypted message to an email address, which does not have an 
associated public lock in the Zendit directory of certificates at server database, the server 
generates an lock and key for the email address and uses the public lock to encrypt the message. 
The encrypted message is sent along with another mail that asks the receiver to register with the 
Zendit system and to download the Zend generated lock and key. During the lock and key 
download process, the user is asked to change the password associated with the lock and key. 



3.7 COM object under MTS for transactions 

All database transactions are implemented in an ActiveX DLL, which is placed under MTS. This 
provides a stable and reliable way of implementing large-scale transactions as well as complying 
with the three-tier architecture. The design, implementation and the security issues involved are 
detailed in the attached document. 



The purpose of this section is to provide an overview of the high-level design implementation of 
the pages in the Zendit Website. This section details the behavior of each of the pages in the site 
and the backend processing that occurs for the user actions on the site. 

The Zendit Website is divided into three sections: 

4.1 User Pages. 

4.2 Administration Pages. 

4.3 Interface pages to SurfBoard. 



4.1 User Pages 

The Zendit website provides an interface for users to register and download the surfboard. 
Registered users can view their personal 'Vault' where their related information is displayed. The 
different options available to the user are: 

1. Registration 

2. Key confirmation 




"COM Design 
Documentdoc" 



4. Zendit Web Site 
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3. 


Login 


4. 


Search 


5. 


Feedback 


6. 


View Vault 




a. Personal Information 




b. Personal settings 




c. Files up!oaded(not applicable now) 




d. Key Pairs uploaded 




e. View Certificates 




f. Change password 




g. Download surfboard. 



6. Forgot password 



The following sections describe each of the options available to the user in detail. 

4.1.1 Registration 

Description 

There are four different ways with which the user can register with the Zendit system. The 
method. The regular registration process is discussed below. The other methods are discussed 
after the basic registration process. 

The page collects user's information for registration. The user is also provided with an option to 
confirm the registration. 

Refer Functional Specification document for details regarding the registration process. 
Validations 

During registration: 

> Check for mandatory fields. 

> Check for the data type. 

> Check for minimum and maximum characters/value required. 

> Check for the format of the primary email ID. 
During registration confirmation: 

> Check if confirmation ID is entered. 
Database activities 

The following table is used during the registration process. 
1. tblRegisteredUsers 

Actions performed: 

> Check for login ID. 

> If login ID exists, a message is displayed to the user to choose a different login ID. 

> If login ID does not exist, a new record is inserted into the table. The password is hashed and 
this password hash is stored in the table. 

> A mail is sent to the user with a confirmation ID. The email ID to which the mail is sent will be 
the primary email ID of the user. 

The mail that is sent to the user would contain the URL for confirmation with the login ID and the 
confirmation ID as parameters. This facilitates the user to be taken to the confirmation page and 
get the registration confirmed. 
For e.g., the URL would look like 
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http://www.Zendit.com/confi imasp?loginlD=^^ 

The user needs to submit his password during his registration confirmation. 



The following tables are used during the registration confirmation process. 

1 . tbIRegistrationConfirmation 

2. tbIRegisteredUsers 

Actions performed: 

> Check for the login ID and confirmation ID combination in the tbIRegistrationConfirmation 
table. 

> If combination does not exist, display message to the user. 

> If combination exists, mark the related record for that login ID in the tbIRegisteredUsers table 
as confirmed and delete the record from the tbIRegistrationConfirmation table. 

The other registration methods are as follows. 

Quick Registratio n 

The Zendit system generates a lock and key for the user when user registers with the system. 
The user can download this lock and key after confirming the registration through the ZPanel. The 
only restriction is that the primary email address provided in the registration should not be 
associated with another user in the Zendit server. 

Vaccine Registration 

The Zendit system generates a lock and key for those email address for which no lock is 
associated in the Zendit server while someone is trying to send an encrypted mail to the email 
address using the Zendit system. Along with the encrypted mail, another mail is sent from the 
Zendit system asking the receiver to confirm that the email address belongs to the receiver. 
When the receiver is not a registered user of the Zendit system and tries to confirm the email 
address, then the receiver has the option of registering with the system. There is no registration 
confirmation process involved with this registration as the user has already confirmed that the 
email address is associated with the registered login. 

Surfboard Registration 

At the end of the Zendit client installation, the setup provides the user with the option of 
registering with the Zendit system. When the user chooses to register, the quick registration 
process is initiated. 

4.1.2 Certificate Confirmation 

Description 

The page provides an option for the user to confirm the key created. 
Refer the FS document for details regarding the key creation process. 

The URL for confirming the Key creation would contain the email ID and Key ID as a parameter. 
For e.g., 

http://www.zend.com/confi rm.asp?loginlD=john&KeylD=12345678 



Zendit Confidential 



Page 31 of 100 



Zendit Design Document 



Validations 

> Check if the confirmation ID is entered. 



Database activities 

The following tables are used during the key confirmation process. 

1 . tbIKeyConfirmation 

2. tblConfirmedCerts 

3. tblNonConfirmedCerts 

Actions performed: 

> Perform the hashing on the login ID to identify the SQL Server to be accessed. 

> Check for the key ID and confirmation ID combination. 

> If combination does not exist, display message to the user. 

> If combination exists, insert a record into the tblConfirmedCerts table with the values from 
the tblNonConfirmedCerts for that key ID. 

> Delete the record from the tblNonConfirmedCerts table and tbIKeyConfirmation table for 
that key ID. 

4.1.3 Login 

Description 

This page provides an option for the user to login to the site to view the web vault. 
Validations 

> Check if the login ID and password are entered. 

> Check for the minimum and maximum characters required. 

Database activities 

The following table is used during the login process. 
1. tbIRegistered Users 
Actions performed: 

> Hash the password and get the password hash 

> Check for the login ID and password hash combination. 

> If combination does not exist, display message to the user. 

> If combination exists, hash the session ID, date and time and get the status hash. Drop a 
session-based cookie onto the user machine with the status hash value in it. 

> This cookie would be read on all the pages to check if the user has logged in. 

> Display the personal vault page. 
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4.1.4 Search 

Description 

This page facilitates the user to search for a particular certificate based on name, email ID or the 
key ID. 

Actions performed 
For Name search: 

The ListEmaillDs table in the admin server is searched for an exact match of the name provided 
For email ID search: 

The ListEmaillDstable in the admin server is searched for an exact match of the email ID 
provided. 

For key ID search: 

The tbIListEmaillDs table in the admin server is searched for an exact match of the key ID 
provided. 

4.1.5 Feedback 

Description 

This page facilitates any user to send his feedback about the Zendit system. The user need not 
necessarily be logged in to the system. 

Actions performed 

The email ID and the feedback from the user are inserted in the tbIFeedback table along with the 
date. 

4.1.6 Vault 

Description 

This page provides an option for the user to view all the information regarding the user that is 
available at the Zendit Server. 

Database activities 

The following table is used while accessing the vault. 
1 . tbIRegisteredUsers 
Actions performed: 

> Access the cookie to see if the user has logged in. 

> If not logged in, display message to the user. 

> If logged in, display the page with appropriate links. 

> Display the remaining free space available to the user and total mails zent by the user. 
These values are obtained from the tbIRegisteredUsers table. 
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4.1.7 Personal information 

Description 

This page is accessed from within the Vault page. This page provides an option for the user to 
view the personal information that is entered during registration. The user is also provided with an 
option to update this information. 

Validations 

> Check for mandatory fields. 

> Check for the data type. 

> Check for minimum and maximum characters/values required. 

> Check for the format of the primary email ID. 

Database activities 

The following table is used while accessing the vault. 
1 . tbIRegisteredUsers 

Actions performed: 

> Access the cookie to see if the user has logged in. 

> If not logged in, display message to the user. 

> If logged in, display the page with values shown in the appropriate fields. 

> On submit of this page, update the information back into the record for that login ID. 

Case handled 

When the user changes the primary email ID, a process similar to the registration is carried out. 
The user is sent mail both to the old primary email ID and the new email ID. While the mail sent to 
the new email ID contains the confirmation ID, the old email ID is sent a mail informing the user 
that a request for change of primary email ID was made. The user would not be able to login into 
either the SurfBoard or the vault till the confirmation ID is submitted. 



4.1 .8 Personal settings 

Description 

This page is accessed from within the Vault page. This page provides an option for the user to 
choose the personal information fields that could be made available to other Zend users. 

Database activities 

The following table is used while accessing the vault. 

1. tbIRegisteredUsers 

2. tbIUserProfiie 
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Actions performed: 

> Access the cookie to see if the user has logged in. 

> If not logged in, display message to the user. 

> If logged in, display the page with values shown in the appropriate fields. Display 
checkboxes next to each field. 

> On submit of this page, check for the fields that are selected. Store this information in 
tbiUserProfile table. 

The selected fields are stored as a string delimited by commas in a single field. 

For e.g., if the user selects First Name, Phone and Address, this information is stored as 
FName,Phone,Address in a field in the record for that login ID. 

4.1.9 Uploaded files 

Note: This option is not present now. 
Description 

This page is accessed from within the Web Vault page. This page provides an option for the user 
to view the file information backedup to the Zendit server. The user is also provided with an 
option to download or delete the uploaded files. 

Database activities 

The following table is used while accessing the vault. 
1. tbIFileUpload 
performed: 

Access the cookie to see if the user has logged in. 
If not logged in, display message to the user. 

If logged in, select all the records from the tbIFileUpload table for that login ID and display 
the information on the page. The file names would appear as hyperlinks. 
Clicking on a file name link would download the file to the client machine. 

Note : This feature is not implemented in the current feature. 

4.1.10 Backed Up Locks and Keys 

Description 

This page is accessed from within the Web Vault. This page provides an option for the user to 
view the locks and keys that are backed up from the SurfBoard onto the Zendit server. The user 
is provided with an option to delete a lock and key by selecting the lock and key to be deleted and 
clicking the delete button. 

Database activities 

The following table is used while accessing the vault. 
1. tbIKeyUpload 



Actions 

> 
> 
> 

> 
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Actions performed: 

> Access the cookie to see if the user has logged in. 

> If not logged in, display message to the user. 

> If logged in select all the records from the tbIKeyUpload table for that login ID and display the 
information on the page. 

When the user selects a lock and key to delete and clicks the delete button, this information is 
posted to another page, which would accept the login ID and key ID as parameters and run a 
stored procedure to delete the record from the tbIKeyUpload table. 

Note: The user is not provided with an option to restore the locks and keys from the site. The 
locks and keys can be restored vault. 

4.1 .1 1 View Certificates 

Description 

This page is accessed from within the Web Vault. This page provides an option for the user to 
view the certificates that are associated with the user on the Zendit server. The user can also 
delete the published lock from the web vault. 

Database activities 

The following tables are used while accessing the vault. 

1. tbIRegiste red Users 

2. tbIConfirmedCerts 

Actions performed: 

> Access the cookie to see if the user has logged in. 

> If not logged in, display message to the user. 

> If logged in, obtain information regarding the email IDs associated with the login ID from the 
tbILoginEmaillD table. 

> Perform the hashing on the email IDs to identify the SQL Server to be accessed. 

> Select the certificate-related information for the email IDs from tbIConfirmedCerts table in the 
appropriate SQL Servers and display this information on the page. The EmaillDs and key IDs 
would appear as hyperlinks. Clicking on those would display the certificate information in a 
simple format. 

4.1.12 Change password 

Description 

This page is accessed from within the Web Vault. This page provides an option for the user to 
change the password for login. 

Validations 

> Check for old password value. 

> Check for new password value. 

> Check for confirmed password value. 

> Check for minimum and maximum characters required. 

> Check if the new password value and the confirm password value match. 
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Database activities 

The following table is used while accessing the vault. 
1. tblRegisteredUsers 
Actions performed: 

> Access the cookie to see if the user has logged in. 

> If not logged in, display message to the user. 

> If logged in, check if the old password matches with the entered old password value. 

> If the values don't match, display message to the user. 

> If values match, update the password value with the new password value after hashing it. 



4.1.13 Forgot password 

Description 

The user would not be able to login into the SurfBoard or the vault in the web site if the password 
is forgotten or lost. The user can request for the password under such circumstances. The user is 
required to submit the login ID and his primary Email ID. If the combination is valid, a confirmation 
ID is generated and inserted into tblReqPwdConf along with the login ID and a mail is sent to the 
user with a link. 

On clicking of the link, the confirmation ID is validated and the user needs to submit his new 
password. The password will be hashed and updated in the database. 

Database activities 

The following table is used while accessing the vault. 

1 . tblRegisteredUsers 

2. tblReqPwdConf 

Actions performed: 

> Check for the login ID and primary Email ID combinationin tblRegisteredUsers table. 

> Generate Confirmation ID and insert into tblReqPwdConf. 

> On click of the link, check for the validity of login ID, confirmation ID in tblReqPwdConf. 

> If valid, the new password is got from the user, hashed and updated. 
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4.2 Administration Pages 



The administration pages are a set of web pages used to manage admin related activities such 
as database related settings, getting statistical information and searching for user information.. 

Access Mechanism will be Windows NT challenge-response authentication. 
4.2.1 Menu Page 

Description 

The page contains the various menu options that are available to the admin. The authorized 
users using Windows NT challenge-response authentication can access this page. The various 
menu options are: 

> Search 

> Statistics 

> Feedback 

> Last Accessed 

> Admin Settings 

> Templates 

> Scripts 

> Mailers 

> Restrictions 

> Help 
> 



4.2.2 Search / User Information Page 

Description 

This page facilitates the admin to search for a particular user based on the login ID, email ID or 
the Key ID. 

Actions performed 
For login ID search: 

The search is done on a pattern match basis and returns all users' login IDs containing the 
search string provided. The tbIListLoginlDs table in the admin server is searched to obtain the 
result. 

For email ID search: 

The search is done on a pattern match basis and returns ail the Email IDs containing the search 
string provided.The tbIListEmaillDs table in the admin server is searched to obtain the result. 

For key ID search: 

The tbltbl ListEmail i Ds table in admin server is searched for an exact match of the key ID 
provided. 

The user information is divided under the tabs as follows: 
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Personal 

The personal details of the user such as the name, address, phone numbers, registration date, 
confirmation date and the last accessed date are displayed under this tab. The admin will have 
provisions for resetting user password as well as deleting the user account. 

The following table is accessed for personal information. 

1 . tbIRegisteredUsers 
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Files 



The uploaded file details such as the name, size, uploaded date, total used space and free space 
left are displayed under this tab. 

The following table is accessed for uploaded file information. 
1. tbIFileUpload 
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Zend Status 

The user's associated email IDs, corresponding key IDs and the number of mails zent by the 
user are displayed under this tab. 

The following table is accessed for key and mails zent information. 
1. tbIConfirmedCerts 
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Feedback 

The details of all feedbacks sent by the user are displayed under this tab. 
The following table is accessed for feedback information. 
1 . tbIFeedback 
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4.2.3 Statistics Page 

Description 

This page facilitates the admin to view various statistics of the Zendit system. The admin can 
select the queries and the date ranges for which he needs to see the results. The admin server 
will be accessed in sequence for all statistical information that the queries generate. The details 
of the statistics that the admin can view are as follows: 

> Zent mails via a particular mail system 

This query allows the admin to view the number of mails that had been sent using SurfBoard 
through a particular mail system (ex - Hotmail, Yahoo). The admin selects the mail system and 
provides the date range for which the statistics has to be shown. The tbIMailsZent table is 
accessed to fetch the result. 

> Number of confirmed registrations 

This query accesses the tbIRegisteredUsers table to find out the number of people who have 
registered and have confirmed by checking the confirmed flag field for a given date range. 

> Total number of Published Locks 

This query accesses the tbIConfirmedCerts table to fetch the total number of digital IDs that have 
been registered with the Zendit system. 

> Average email IDs per user 

This query accesses the tbIConfirmedCerts table to find out the average number of digital IDs per 
person that has been registered with the Zendit system. 
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> Average number of files per user 

This query accesses the tblFileUpload table to fetch the average number of files uploaded per 
user. 

> Average file space used per user 

This query accesses the tblFileUpload table to fetch the average uploaded file space used per 
user. 

> Total Number of Surfboard downloads 

This query accesses the tbISurfboardDownload to find the number of surfboard downloads that 
have happened during a given date range. 

> Total number of logged in users 

This query accesses the tbILoginStatus table to find the number of users who have logged into 
website and through surfboard at any point of time. 

> Number of Interim Lock and Keys in the server 

This query accesses the tbITempKeyPairPool in the selected server to find the number of unused 
interim locks and keys. 
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4.2.4 Feedback Page 



Description 

This page allows the admin to view all feedback that was received by the Zendit system on a 
given date range. When the admin clicks on a particular feedback, a new window that pops up 
will provide the interface for the admin to do the following: 



> To delete the feedback 

> To mail back with the reply to the user. 

The following table is accessed for feedback information. 
1 . tbIFeedback 
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4.2.5 Last Accessed Page 

Description 

This page allows the admin to view all users who last accessed the Zendit system between two 
dates. The admin is provided with the interface to do the following activities: 

> Reset the password and send a mail. 

> Delete the user accounts. 

The following table is accessed for last accessed information. 
1. tbIListLoginlDs 
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4.2.6 Admin Settings Page 



Description 

This page allows the admin to change settings related to the Zendit system. The settings that can 
be changed are as follows: 



> The total file space limit per user. 

> The root path for file uploads. 

> Locks and Keys per user. 

> Maximujm published locks per user. 

> Duration for key pair confirmation. 

> Duration for registration confirmation. 

> Duration for keeping the intrim lock and key in the server 

> Time limit for inactivity. 

> Time limit for sending reminder mails to the user regarding last accessed date. 

> The template version number. 

> 

> DSN string. 

> Current Zendit Client Version. 

> Critical Zendit Client Version. 

> Time limit for running cleanup script (to cleanup the records in tbILoginStatus who have 
logged in but have not used the system more than the specified time.) 



The following table is updated for admin settings. 
TbIAdminSettings 
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4.2.7 Templates Page 



Description 

This page allows the user to update the templates for mailsystems, Frame based and Non Frame 
based usage. The admin will also be able to add new mail system templates. After updating the 
templates, the template blob is created and when the application variables are refreshed, the 
template version number in tbIAdminSettings is increased by one. 

The following table is accessed for template information. 

1. tbITem plate 

2. tbISendTemplate 

3. tbIReadTem plate 

4. tbICIickTemplate 
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4.2.8 Scripts 

Description 

This page contains the manual scripts needed for performing various maintenance and cleanup 
related tasks and also the scripts to send mails that were not sent . 
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4.2.9 Mailers 

Description 

This page contains all the mail contents. The admin will be able to update the mail content also. 
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ZENDIT - The next generation of Internet 
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The ZEND IT mission is to empower individuals with 
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4.2.10 Restrictions 



Description 

This page is used to maintain a list of all the denied persons and companies. We can also add 
restricted countries to the list. 
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4.2.11 Help 

Description 

This page contains the help mappings between the identification code and the help page. The 
admin can add or update the mapping value. 
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4.3 Interface pages to SurfBoard. 

These set of pages act as an interface to the SurfBoard. Any data needed by the SurfBoard will 
be requested to these pages. These pages in turn query the database and send the necessary 
data to the SurfBoard. 

The following table depicts the various pages and the parameters sent and received. Each page 
is explained in detail after the table. 

Interface pages between SurfBoard and Zendit Server 







6 ie s 






Hp 








Loain Reauest 


strLogin 


INewMailStatus 






strPwd 


StrFirstName 


as? 




AgTempKeyExists 


INewTemplateVer 








INewSurfBoardVer 








INewSurfBoardCriti 


Tz 






cFactor 








CStatusHash 


; 






CleanupTime 








flgStatus 








StrSQLServer 








MailFooter 








MailHeader 




Reauest email IDs and Kev IDs 


strLogin 


flgStatus 


Saris: 




strSQLServer 


iCount 






strStatusHash 


strEmailldfi] 








strKeyld[i] 








AgKeyRetStatusfi] 




New Mail Status Request 


strLogin 


flgStatus 






strSQLServer 


flgMailStatus 






strStatusHash 






Reauest Templates 




flgStatus 








strTem plates 








strPassword 




Reauest recipients' public kevs 


strEmailldp] 


flgStatus 






strLogin ID 


iCount 
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strSQLServer 
strStatusHash 



strCertp] 
flgStatus[i] 



Backup Lock and Kev 



strLogin 



flgStatus 



StatusHash 

strSQLServer 

strKeyPairData 

strEMailld 

strKeyld 

strName 

flgReplaceStatus 
strStatusHash 



Restore Lock and Key 



Public Kev U pload 



strLogin 

StatusHash 
strSQLServer 



strLogin 

strPwd 

strEmailld 

strSQLServer 

strSQLNameForRe 

place 

strName 

strCert 

strKeylD 

strMailSystem 

strAlgo 

strLength 

dtCreatedate 

dtExpiryDate 

strStatusHash 

iReplace 



FlgStatus 

iCount 

strEmailld[i] 

KeylD[l] 

Name[l] 

FileBiob[l] 



flgStatus 
flgEmailExists 
strSQLServer 
strKeyld 
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Get User Personal Info 


strEmailld 
strKeyld 


FIgStatus 

<all public personal 

info 

strKeyld 

strCertificate 

strEmailld 

dtExpiry 


Public kev delete 


strLogin 

StatusHash 

strSQLServer 

strEmailld 

strKeyld 


fIgStatus 


Temporary kev pair creation reauest 


arrEmailld(i) 


fIgStatus 
arrCertStatus(i) 
arrKeylD(i) 
arrPuhlirCprtM 




Mailfs) Zend notify 


strLogin 

strSQLServer 

strFmailidni 

strTempEmaillDList 

strMailSystem 

strStatusHash 


fIgStatus 


Reset mail status 


strLogin 

strSGLSprvpr 

strStatusHash 


fIgStatus 


Download Temporary Keys 


strLogin 

StatusHash 

strSQLserver 


fIgStatus 

iCount 

strEmaillD[i] 

KeylD[i] 

FileBlobpJ 




Transparent Loain into Vault 


StrLoginID 

StrStatusHash 

StrSQLserver 







4.3.1 Login Request 
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When the user tries to login, a request is sent to the Server from the Surfboard, 

Fields sent from the SurfBoard to the Server 

strLogin - The login ID which the user gives. 

strPwd - The password given by the user 

flgTempKeyExists - If this flag is set, the server will return the number of Zendit Created keys 
existing for this loginlD. 

Fields returned from the Server to the Surfboard 

flgStatus - A flag that indicates to the SurfBoard whether the login has succeeded or not. 
strSQLServer - The SQL Server name in which the user's details are stored. 
INewMailStatus - The flag to indicate if there is a new mail. 
StrFirstName - First name of the user who has logged in. 
INewTemplateVer - The latest version number of the templates. 
INewSurfBoardVer- The latest version of surfboard 

INewSurfBoardCriticFactor - The version of surboard in the user's machine should be above or 
equal to this number. 

CStatusHash - hash(sessionlD + date + time) 
ICIeanUpTime - The timelimit for cleaning up tbILoginStatus. 
MailFooter- The content that goes as footer in all the mails zent. 
MailHeader - The content that goes in the header in all the mails zent. 
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Server Action 

The Server receives the login ID and the password from the SurfBoard and hashes the password 
using the fnHash method and checks for the validity of the hash. Login can fail for any one of the 
reasons below: 

> SQL Server connection failure. 

> The user has not yet confirmed his registration. 

> Invalid login ID or password. 

Accordingly, flgStatus will carry an error code to the SurfBoard. 

Every time the user logs in, a hashing is done on the login ID and the Server will find the SQL 
Server in which the user's data is stored. The SQL Server's name is passed onto the Surfboard, 
so that for further fetching of data from the database, all the SQL Servers need not be searched. 

If the Login is successful, hashing is done on the string formed by concatenating the session ID, 
date and time. This hash is sent to the client as well as stored in a database table tbILoginStatus 
along with login ID and the date - time stamp. This entry is made in the corresponding 
SQLServer in which the user's data is stored. 

iNewTemplateVer is the version of the template which is currently in the database. This version 
number is compared with that of the SurfBoard registry entry and if they differ, a request is made 
from the SurfBoard to the Server to download the recent version of template. This comparison 
avoids the need for downloading the templates every time the user logs in. 



A message indicating whether the user has successfully logged in will be displayed to the user. If 
login succeeds, a low priority thread is started to fetch the email IDs associated with the login ID. 

4.3.2 Request email IDs and Key IDs 

The SurfBoard makes a request to the Zendit Server to download the key IDs and corresponding 
email IDs for the login ID. 

Fields sent from the SurfBoard to the Server 

strLogin - The login ID of the user 

strSQLServer - The SQL Server name in which the details of that user is stored. 

StrStatusHash - The unique value which is passed on to surfboard while logging in the user. 

Fields returned from the Server to the Surfboard 

flgStatus - The flag that specifies whether the operation has succeeded or not. 

'Count - Number of email IDs associated with that login ID. 

strEmaillDp] - Array of email IDs. 

strKeylD[i] - Array of key IDs. 

f!gKeyRetStatus[i] - Array indicating status for each email ID 

Server Action 

The server contacts the SQLServer and validates the statushash in tbILoginStatus. If the 
statushash is valid, the server fetches the list of email addresses associated with the user name 
from tbILoginEmaillD. Then, each email address is hashed and the SQL server is identified. The 
Key IDs for the email address is got from tbIConfirmedCerts from that server. 
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4.3.3 New Mail Status Request 

The SurfBoard requests for the new mail status of the user who has logged in. 
Fields sent from the SurfBoard to the Server 
strLogin - The login ID of the user 

strSQLServer - The SQL Server name in which the details of that user are stored. 
StrStatusHash - The unique value that is passed on to surfboard while logging in the user. 



Fields returned from the Server to the Surfboard 



flgStatus - The flag which indicates whether the operation has succeeded or not. 
flgMailStatus - The flag which indicates whether there is a new mail or not. 

Server Action 

This page accesses the tbiRegisteredUsers for the new mail status flag for the login ID after 
verifying the status hash in the tbILoginStatus. This information is indicated to the SurfBoard 
through the flgMailStatus flag. 

4.3.4 Request Templates 

The SurfBoard sends a request for the new templates from the Zendit adminserver. This request 
is made from the SurfBoard if the template version with the SurfBoard is different from the one in 
the database. 

Fields sent from the SurfBoard to the Server 



Fields returned from the Server to the Surfboard 

flgStatus - The flag indicates whether the operation has succeeded or not. 

strTempiates - Set of mail system templates available in the database. 

Password - The password used for encrypting the template blob. 
Server Action 

When the server receives the request, the template will be downloaded to the SurfBoard. 



4.3.5 Request recipients' public keys (certificates) 

If the user is zending mails, the SurfBoard searches the local key ring for the recipients* public 
keys. If the public key for few of the recipients doesn't exist in the local key ring, the SurfBoard 
will request those public keys from the Zendit server by sending the email IDs as parameters. 

Fields sent from the SurfBoard to the Server 

strEmaillDp] - Array of email IDs for which the certificates have to be fetched from server 
strLogin - The login ID of the user 

strSQLServer - The SQL Server name in which the details of that user are stored. 
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StrStatusHash - The unique value that is passed on to surfboard while logging in the user. 
Fields returned from the Server to the Surfboard 

flgStatus - The flag that indicates whether the operation has succeeded or not. 

iCount - Number of email IDs for which the public keys are to be fetched from database. 

strCertfi] - Array of certificates 

flgStatus[i] - Array of status flags which indicate the status of each certificate. (Whether it 
exists in the server or not) 



Server Action 



The status hash value is validated with the value in tbILoginStatus in the SQL Server. Then each 
email address is hashed and the SQL Server is identified. The tbIConfirmedCerts table is queried 
for every email ID and stored in an array. This array is then sent to the SurfBoard. 

4.3.6 Backup Lock and Key 

The SurfBoard requests this page to backup the user's lock and key to the Zendit server. 
Fields sent from the SurfBoard to the Server 



strLogin 
StatusHash - 
during login 
strSQLServer 
strEMailld 
strKeyPairData 
strKeyld 
strName 

flgReplaceStatus 



■ The user's login ID. 

The hash value of sessionld+date string which was sent to surfboard 

The SQL Server name in which the details of that user are stored. 

The email ID for which the user has created the lock and key. 

The private, public key pair created for the email ID. 

The key ID that has to be uploaded. 

Name of the user that will appear in his certificate. 

Status flag indicating whether to replace the key or not. 



Fields returned from the Server to the Surfboard 



flgStatus - The flag which specifies whether the operation has succeeded or not. It also 
specifies whether lock and key for that email ID already exists in the database. 

Server Action 

The value of the status hash is validated with the value in the tbILoginStatus in SQLServer. 
The Zendit server receives the email ID and lock and key that has to be backed up along with 
SQL Server name. The server queries the tbIKeyUpload table whether a lock and key already 
exists for that email ID. If so, this information is passed onto the SurfBoard through the flgStatus, 
else the lock and key is backed up. 

If a lock and key already exists for the email ID specified by the user, then the user will be given 
an option to replace the existing one. If the user chooses to replace, a request is made again. 
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4.3.7 Restore Lock and Key 

The SurfBoard requests this page to restore the user's key pair from the Zendit server. 
Fields sent from the Surf Board to the Server 
strLogin - The user's login ID. 

StatusHash - The hash value of session Id+date string whichwas sent to surfboard during login 
strSQLServer - The SQL Server name in which the details of that user are stored. 
Fields returned from the Server to the Surfboard 

FlgStatus - The flag that indicates whether the operation has succeeded or not 

Icount - Number of email ID - key pair of the user that are in the database. 

StrEmaillD[i] - Array of email IDs of the user for which key pairs are present in the database. 

KeylD[l]- Array of Key IDs 

Name[l] - Array of the corresponding names 

FileBlob[l] - Array of the corresponding fileblobs 

Note: There can be only one lock and key associated for an email ID but the user can backup 
more than one lock and key. 

Server Action 

The server receives the user's login ID and the SQL Server name in which the details of user are 
stored. The value of the status hash is validated with the value in the tbILoginStatus in 
SQLServer. 

The server fetches all the email ID - key pairs of the user from the tbIKeyLlpload table and passes 
onto the SurfBoard. 



4.3.8 Public Key Upload 

The SurfBoard requests this page when the user uploads his public keys to the Zendit server 
database. 

Fields sent from the SurfBoard to the Server 

strLogin - The user's login ID. 

strPwd - The user's password. 

strSQLServer - The SQL Server name in which the details of that user are stored. 
strEmailld - The email ID for which the public key has to be uploaded. 
strName - The name of the user as it appears in the certificate. 
strCert - The certificate which has to be uploaded. 

strKeylD - The key ID. 

iReplace - The flag which indicates whether to replace if a certificate already exists in the 

database for that email ID. (This flag will be null during the first request). 

StrStatusHash - The unique value that is passed on to surfboard during login 

StrMailSystem - Mail system of that email address. 

StrAlgo 

StrLength 

dtCreatedate 
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dtExpiryDate 

(properties of the certificate that is published) 



Fields returned from the Server to the Surfboard 



flgStatus - The flag which indicates whether the operation has succeeded or not. 

flgEmailExists - The flag which indicates whether a certificate already exists in the database for 
that email ID. 

strSQLServer - The SQL Server name in which the certificate details of the user are stored. 

flgKeylD - Key ID 



Server Action 



The Zendit database is checked whether a certificate already exists for that email ID. If it exists, 
then server sets the "flgEmailExists" flag and passes it to the SurfBoard. The user will be given an 
option to replace the existing one or not. The SurfBoard in turn sets the "iReplace" flag and again 
sends the request to the server with all the other values. The server updates the database 
accordingly. 

4.3.9 Get User Personal info (this functionality is not used) 

The SurfBoard requests this page to fetch the user information for a given email ID. 

Fields sent from the SurfBoard to the Server 

strKeylD - The associated key ID of the email ID. 

strEmaillD - The email ID for which the user wants to find the details. 



Fields returned from the Server to the Surfboard 



flgStatus - The flag which indicates whether the operation has succeeded or not. 
strKeylD - The associated key ID of the email ID. 
strCertificate - The certificate associated with the email ID. 
strEmaillD - The email ID. 

<all public info>- This information depends on the choice of the user whose information is being 
requested. 

dtExpiry - The certificate's date of expiry. 
Server Action 

The tbIRegisteredUsers table is accessed for retrieving the user's information. TbIUserProfile is 
accessed for retrieving the choice of the user. 



4.3.10 Public key delete 

The SurfBoard requests this page when the user deletes any of the uploaded keys. 
Fields sent from the SurfBoard to the Server 
strLogin - The user's login ID. 

StatusHash - The hash value of sessionld+date string which was sent to surfboard during login 
strSQLServer - The SQL Server name in which the details of that user are stored. 
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strEmailiD 
strKeylD 



- The email ID for which the user wants to delete the key ID. 

- The key ID which the user wants to delete. 



Fields returned from the Server to the Surfboard 



flgStatus 



- The flag which indicates whether the operation has succeeded or not. 



Server Action 



The EmaillD is hashed to find the corresponding SQL server. A connection is made to that server 
and theCorresponding record is moved from tbIConfirmedCerts table to the tbIBadCerts table with 
a flag indicating "Delete" mode. The corresponding entry is also deleted from tblListEmaillDs and 
tbILoginEmaillD . 

4.3.11 Temporary key pair creation request 

The SurfBoard sends a request to the server to create a interim locks and keys for those email 
IDs in the recipient's list for which the public keys are not available. 

Fields sent from the SurfBoard to the Server 

StrLoginID - Login ID of the user 

StrSQLServer - The SQL Server name in which the details of that user are stored. 

StrStatusHash - The unique value passed on to surfboard during login. 

StrEmaillDList(i) - The email ID list for which the SurfBoard requests the certificates. 

Fields returned from the Server to the Surfboard 

flgStatus - The flag that indicates whether the operation has succeeded or not. 

arrCertStatus(i) - The status flag which indicates the source of the certificate( 
confirTTiedcerts/confimiedtempkeys/tblTempKeyConfirmation/tblTempKeyPairPool) 
arrKeylD(i) - the array of key Ids for the Email Ids. 
arrPublicCert® - the array of certificates. 

Server Action 

The server checks whether a key ID already exists for that particular email ID in the 
tbIConfirmedCerts or in tbIConfirmedTempKeys or in tbITempKeyConfirmation table. If it exists, 
flgStatus will be sent to the SurfBoard accordingly. If the key ID doesn't exist , the mail will be 
sent using the new public key that was created(tblTempKeyPairPool) and sent by the server to 
the SurfBoard. 



4.3.13 Mail(s) Zend notify 

The SurfBoard requests this page to update the number of mails zent and the new mail status of 
all recipients. 

Fields sent from the SurfBoard to the Server 
strLogin - The user's login ID. 

StrSQLServer - The SQL Server name in which the details of that user are stored. 
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strMailSystem - The mail system from which the mail is sent. 
strEmaillDp] - Array of email IDs in the "TO" list. 

StrTempEmaillDList - List of EmaillDs for which the ZendSystem created KeyiDs. 
StrStatusHash - Unique value passed on to surfboard when the user logs in. 

Fields returned from the Server to the Surfboard 

flgStatus - The flag which indicates whether the operation has succeeded or not. 

Server Action 

tbIMailsZentLogin in strSQLserver will be updated for the corresponding LoginID and 
tbIMailsZent in the admin server will be updated for the corresponding mailsystem and date. 
Mails will be sent to all the email IDs in the strTempEmailList 



4.3.14 Reset mail status 

The SurfBoard requests this page to reset the new mail status flag once the user reads a mail 
using dezend. 

Fields sent from the SurfBoard to the Server 
strLogin - The user's login ID. 

strSQLServer - The SQL Server name in which the details of that user are stored. 
StrStatusHash - The unique value that is passed on to surfboard when the user logs in. 

Fields returned from the Server to the Surfboard 

flgStatus - The flag which indicates whether the operation has succeeded or not. 
Server Action 

The tbIRegisteredUsers table is updated by resetting the new mail status flag for the given login 
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4.3.15 Download Temporary Keys 

The SurfBoard requests this page to download the interim lock and keys for the corresponding 
LoginID from the Zendit server. 



Fields sent from the SurfBoard to the Server 
strLogin - The user's login ID. 

StatusHash - The hash value of session Id+date string whichwas sent to surfboard during 
login 

strSQLServer - The SQL Server name in which the details of that user are stored. 
Fields returned from the Server to the Surfboard 

FlgStatus - The flag that indicates whether the operation has succeeded or not 

Icount - Number of email IDs - interim lock and keys of the user that are in the 

database. 

StrEmaillDfl] - Array of email IDs of the user for which interim lock and keys are present in the 
database. 

KeylD[l]- Array of Key IDs 

FileBlobfl] - Array of the corresponding fileblobs 

Server Action 

The server receives the user's login ID and the SQL Server name in which the details of user are 
stored. The server fetches the email ID list for the corresponding LoginID from tbIILoginEmaillD 
for which interim lock and key exist. Then, keylD and the keypairblobs are retrieved for each 
emaillD from tbIConfirmedTempKeys from the corresponding server which is identified by 
hashing the email address. 

4.3.1 6 Transparent Login to Vault 

The surfboard requests this page to bring up the webvault inside the vault. 
Fields sent from the SurfBoard to the Server 
strLogin - The users login ID. 

StatusHash - The hash value of sessionld+date string which was sent to surfboard during 
login 

strSQLServer - The SQL Server name in which the details of that user are stored. 
Server Action 

The server checks the valididty of the statushash in tbILoginStatus. If it is valid, the web vault for 
the corresponding login is brought up inside the vault. Else, the login page is brought up. 
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5. Surf Board Components 



U f I f i 

id *j 



!J 25 J 






is User ; J 










•••• ^™7i 




Browser Abstraction 
Layer (BAL) 







^ ► 



Zendit Confidential 



Page 64 of 100 



Zendit Design Document 



5.1 Login Manager 




[suiathamanohai 



User Name: 
Password: 



OK 




Login Name: The login name of the user as specified in the registration page at Zendit.com. 

Password: The password of the above login name as specified in the registration page at 
Zendit.com. 

Save Password: The option for the user to store the password in the protected storage on the 
local machine. 

Description 

Login Manager (LM) module takes care of logging in the user and maintaining the user's identity 
until the user exits the SurfBoard. LM logs in the user either by presenting the user with the login 
name/password dialog or in the case of auto login, it gets the user info from the protected 
storage. The LM maintains the state whether the user has logged in or not. Every other module 
that requires the user to be logged in queries the login manager and then performs the required 
action The LM prompts the LSM to store the login name and password, which is requested by 
the web server agent to be passed, to communicate to the web server. 

If the user selects the save password option, the Login Manager initiates the LSM to save the 
login name and password in the protected storage. The login name and password are encrypted 
and stored, which prevents the misuse of the registry values. 

Assumptions 

Once the user has logged in and opens another instance of Internet Explorer, the user 
information is taken from the login manager. 

Similarly, as soon as the user logs out, user will be logged out of all the SurfBoard instances. 
Limitations 

In effect, only one user can logon to the SurfBoard on a system at a time 

SurfBoard stores only the last logged on user name and password (if save password is selected). 
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5.2 Browser Agent 

Description 

Browser Agent module interacts with the web browser (Internet Explorer) which hosts the 
SurfBoard. When the user is in the Compose, Reply, Forward page of a mailsystem which the 
zendit system supports and if the user initiates a "Zendit", the SurfBoard module requests the 
Browser Agent to fetch the values from the various fields like To, From, Cc, Bcc. The Browser 
Agent module gets the names of the various tags for the To, From, Cc and Bcc fields from the 
Template Manager. Using these tags the Browser Agent fetches the required values from the 
current page and passes them to the SurfBoard module. 



5.4 Local Storage Manager (LSM) 

Description 

The local storage module manages all local data storage (includes: configurable SurfBoard 
options, saved user names and pass phrases, email system templates). All SurfBoard modules 
store and retrieve local data through the LSM, which provides them a single virtual view of 
Zendit's local storage. This allows us to maintain the flexibility to modify or migrate our local 
storage locations and methods. 

5.5 Template Manager 

Description 

The Template Manager maintains the various information regarding the various mail systems' 
web pages. The template actually consists of the URL for Compose, Reply, Forward or Read 
page along with the various other information as specified in the database. This information is 
used by the Browser Agent to get the values from the To, From, Cc and Bcc fields. When the 
SurfBoard is started for the first time, it downloads the templates from the web server and stores 
in the local machine. Whenever a new version of the templates is put on the web server, the 
Template Manager downloads the latest version of Templates by requesting the Web Server 
Agent. 

Assumptions: 

The Administrator maintains the correct templates of the various mail systems' web pages. 
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5.6 Web Server Agent 

Description 

The Web Server Agent takes care of all the communication between the SurfBoard and the web 
server. Whenever the data is needed from the server, Web Server Agent communicates with the 
server by sending appropriate request.The data is received in the form of customised XML tags. 



5.7 SurfBoard Module 

Description 

The SurfBoard module coordinates with all the other modules and processes the user's requests. 
As soon as the user selects SurfBoard from View / Explorer Bar (Menu of Internet Explorer), the 
SurfBoard module instantiates the User Interface. The SurfBoard module logs in the user with the 
help of the Login Manager. When the web server authenticates the user and sends the result, it 
also sends the latest template version to the SurfBoard. The SurfBoard module passes this 
template version information to the Template Manager, and the necessary action is taken. The 
SurfBoard module starts a low priority thread, which downloads the email IDs and the 
corresponding key IDs of the current user by requesting the Web Server Agent. When the user 
initiates a "Zendit" request, the following actions occur: 

> The SurfBoard module requests the Browser Agent to get the values from the To, From, Cc 
and Bcc fields. 

> It checks for the public keys corresponding to the mail IDs in the To, Cc and Bcc fields. This 
checking is done in the following order: 

• Checks in the local key ring. 

• If the public key doesn't exist in the local key ring, it searches for the public key in the 
Zendit server database and if it finds a match, it downloads the public key to the local 
key ring. 

• If the public key could not be found in the local key ring or in the Zendit server 
database, it asks the user if a interim lock and key has to be created for that email ID 
on the server. 

o If yes, a call is made to WSA to create interim lock and key. 
o If no, that email ID is removed from the To, Cc or Bcc list. 

The SurfBoard module contacts the Key Manager for all key related activities. 
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5.8 SurfBoard Ul 

Description 

SurfBoard Ul module is the interface between the user and all the Zendit functionality. This 
handles the SurfBoard that gets attached to the Internet Explorer browser window and allows the 
user to encrypt mails using any supported mail system. 



■^1 Welcome to Microsoft's Homepage - Microsoft Internet Ettploi 




Product Families 

Windows 
Office 
s&rVers 

Other Pro ducts 
Information For 

Businesses 
lTPrtrffiSSiOhal* 
Devefopera 
Microsoft Partners 
Educators 
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Support 

windows tipdate 

Office t-po I? 

hGentra) 

Shop 
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of Windows 2000 
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For the Office XP 
launch, find cooJ 
deal; on software, 
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lOffice^ 



* Whim zm sre 
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compatibility, 
reliability, security, 
and setup, 

Betth« latest video 
and audio pi a;, erf for 
PC and Pocket PC, 

offer; neu integrated 
messaging and privacy 
features. 




1 ^ 



Assumptions 

When the user zendit(encrypts) an email, the mail is signed, compressed and encrypted. The 
encrypted text is then converted into an ASCII armor, which replaces the original message body 
in the email. 
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Limitations 

> When a user Zends an email, the new mail status of all the recipients is updated. This is 
unrelated to actual delivery or receipt of the email since those are handled by the individual 
mail systems and are outside our control. 

> When the user receives an email with digital signature, the digital signature cannot be verified 
if the certificate used for signing is not available either in the local key ring or on the Zendit 
server. 

> User will be able to re-encrypt an email for a different user(s). 

> The file that goes as an attachment in a mail will not be automatically encrypted or decrypted 
The user cannot be intimated about attachments accompanying a mail.The system would not 
be able to resolve nick names to the appropriate email ID while Zending mails. 

> Once user decrypts an email, it will be temporarily decrypted and displayed on the web 
browser. Since the email is stored in the mail system the user cannot save a decrypted copy 
of the email. Hence, the user must decrypt the email every time it is to be viewed. 



5.9 CSP 

Description 

Cryptographic Service Providers' (CSP) are independent modules that provide the cryptographic 
services to the application. It is written to be completely independent of any particular encryption 
algorithm, so that the Zendit SurfBoard application may, in future, work with a variety of CSPs. In 
practice, however, some modifications may be required to fully support multiple CSPs An 
interface between the Zendit application and OpenLib CSP SDK will be implemented to maintain 
the application's independence from the underlying encryption technology. This makes replacing 
the OpenLib CSP SDK by another cryptography system in future relatively easy. 

CSP functions can be categorized into the following sections: 

> Key Management 

> Encryption/Decryption functions. 

> General functions. 



CSP functions 



OpenLib 


CSP 


SDKSDK 






Assumptions 



Key DB 
(Key Ring) 



The OpenLib CSP is viewed as a complete, reliable package and will be used as is. Hence this 
will not be tested. 
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5.10 Text or File Encryption 

Description 

The user can encrypt text or a file by selecting an appropriate menu item. If the user has logged 
in, either symmetric key encryption or public key encryption can be used. If the user has not 
logged in, only symmetric key encryption can be used (i.e. the option of public key encryption is 
disabled). 

5.10.1 File encryption using public key 





Select Source and Destination Files 



Enter the source and destination for the files you want to encrypt. 
To distinguish the original unencrypted source file from the 
encrypted destination file, they must have different path or file 
names. 



Source file: 



| D : \personal docsSmo vingthoughts. txt 




Destination file: 



p : \personal docs\mo vingthoughts20. txt 





Zendit Confidential 



Page 70 of 100 



Zendit Design Document 



Zendit - Fife Encryption Wizard 



rfixi 



Select Algorithm/Public Lock 

Select one or more of the public locks listed below. If you are 
encrypting this for yourself, make sure that you have the associated 
private key to decrypt. 



fa? ".f..UM 



(* Public Lock Encryption 
Symmetric Lock Encryption 



lleyJP^ 



□(I navinc@aditi.com <navine@aditi.com> 8B683BCBX 
□^4 sujatham@aditi.com <sujatham@aditi... ( EOT DDG2F <r j 

, 71: s ; J: 2J 



Zendit - File E ncryptign Wizard 



Select Digital Signature 

Select the digital signature you wish to sign this document with. 
Your digital signature verifies the file's authenticity - that it 
originated from you and that it has not been tampered with. 

W' Sign with the private key listed below 



jsujatham(gaditi com < suiatham@aditi.com > EQ1 DD62f 
Password: 

r 

Remember my password W Set as default signature 



r ASCII Armored Output 



« 



Encryption Type: The encryption algorithm to be used. 
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Choose Public Key: The user has to choose one Public key among the keys present in the key 
ring for public key encryption. 

File Name: The actual file to be encrypted. 

Encrypt: Encrypt the file specified with the selected public key. 

Select Digital Signature: The user is provided with an option to sign the encrypted file. He can 
choose the private key to sign. 



The specified file is encrypted using the public key selected and the resulting file is stored in the 
location specified by the user. 



5.1 0.2 Text encryption based on public key 



Description 





Type or paste text to Encrypt 

Type the text you wish to encrypt into the text box below, if you 
have text saved to your clipboard, click the 'Paste' button. 



Hello World 



P WordWrap 
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Zendit - Text Encryption Wizard 




Select Algorithm/Public Lock 

Select one or more of the public locks listed below. If you are 
encrypting this for yourself, make sure that you have the associated 
private key to decrypt. 

j Public Lock Encryption j 
hf* Symmetric Lock Encryption 











navinc@aditi.com <navinc@aditi.com> 


8B638BCBjUJ 




suiatham@aditi.com < suiatharn@aditi.. . . 




a;,, 


; :.l , \ 


E01DDG2Jrj 



Zendit - Text Encryption Wizard 



X 



Select Digital Signature 

Select the digital signature you wish to sign this document 
with. When the tent is decrypted, your digital signature verifies the 
authenticity of the data that it originated from you and has not 
been tampered with. 

W Sign with the private key listed below 



j j sujatham^ > E01 DP 62P »J 

j Password: 



j W Remember my password W Set as default signature 

W ASCII Armored O-Out 



Encryption Type: The encryption algorithm to be used. 

Choose Public Key: The user has to choose one Public key among the keys present in the key 
ring for public key encryption. 



Text To Encrypt: The user has to enter the text to be encrypted. 
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Encrypt: Encrypt the text with the selected key. 

Select Digital Signature: The user is provided with an option to sign the encrypted text He can 
choose the private key to sign. 

Description 

The text entered is encrypted using the public key specified and the result is displayed. 



5.10.3 File encryption based on symmetric key 



Zendit - File Encryption Wizard 




Select Source and Destination Files 

Enter the source and destination for the files you want to encrypt. 
To distinguish the original unencrypted source file from the 
encrypted destination file, they must have different path or file 
names. 

Source file: 

j D:\personal docs\movingthoughts.txt 



Destination file: 

jDApersonaldocs\movingthoughts22itxt 
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Zendit - File E ncrjrption Wizard 



U3 




Select Algorithm/Symmetric 

Symmetric lock encryption uses the password you specify to lock 
the encrypted file. Decryption takes place using the same 
password For a higher level of protection and access control we 
suggest using public lock encryption. 

j C Public Lock Encryption 
I ^ iS^fiiieiiic Egc^ 




Zendit - File E ncryption Wizard 



Enter and confirm a Password 

Enter and confirm the password to symmetrically lock the file. 



i Enter Password: 

I — 

I Confirm Password: 



P ASCII Armored Output 




Encryption Type: The encryption algorithm to be used. 

Symmetric Key Algorithm: The user selects the algorithm for symmetric key encryption. 
Symmetric Key Password: The user has to enter the password for the symmetric key encryption. 
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File Name: The file to be encrypted. 

Encrypt: Encrypt the file specified with the algorithm selected. 

Description 

The specified file is encrypted using the selected symmetric key algorithm and the resulting file is 
stored in the location specified by the user. 



5.10.4 Text encryption based on symmetric key 



Zendit - Text Encryption Wizard 



Type or paste text to Encrypt 



Type the text you wish to encrypt into the text box below, if you 
have teat saved to your clipboard, click the 'Paste' button. 



Hello World 



F WordWrap 
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Zendit - Text Encryption Wizard 



Select Algorithm/Symmetric 

Symmetric lock encryption uses the password you specify to lock 
the encrypted text. Decryption takes place using the same 
password For a higher level of protection and access control we 
suggest using public lock encryption. 

rr : 

] * Public Lock Encryption 
j ISKjnmjseiric.^ 



Zendit - Text E ncryption Wizard 



Enter and confirm a Password 

Enter and confirm the password to symmetrically encrypt the text 



\ Enter Password: 

I I — = 

1 Confirm Password: 



I r 



Encryption Type; The encryption algorithm to be. 

Symmetric Key Algorithm: The user selects the algorithm for symmetric key encryption. 
Symmetric Key Password: The user has to enter the password for the symmetric key encryption. 
Text To Encrypt: The user has to enter the text to be encrypted. 
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Zendit VaultfDetails) 



ll& sujatha - Vault 



2&ak jaSfc / Vtew Keys: Egraj?pfc D-ecryp^: |feip 



MEMO 




^ lag sat :: 1 wefevrt 




3 




Use this area to view details and manage 
Pubtc Locks (for encryption) and Private 
Keys (for decryption). 

To create a new Lock and Key, click on 
the: Create* icon (shaped like a key} and 
the Zendit System will guide you thiough 
Hie creation. 

To get details on Locks and/or Keys 
double click a Lock and/or Key and the 
details will be displayed. 

To manage Locks and Keys: Use the 
menu bar or right click on the Lock and 
Key you wish to manage, You can import, 
export, copy, and delete your Locks and 
Keys You can also synchronise, store, 
and restore to and from youi Web Vault. 



navinc@aditicom<navinc@aditicom> 8BGB8BCBA1 9757GF 1024 RSA 

§4 suiatham@aditi.com <suiatham@aditi.com> EQ1DD62F7Q6D6675 763 RSA 

^ZendMailSuppoFt@adiUcom<ZendMaiISupport@aditic 04535 FE50GCC5701 768 RSA 



Zendit Confidential 



Page 79 of 100 



Zendit Design Document 



View Web Vault 



J sujatha - Vault 



§% ! A*' ^ : A i JSC* 4^ , rFr^- 



Q3E 




r J 



xend H 



Zendit Vault shows the details of all the keys, available in the Vault 
Functioning 

This module passes the user requests to the 'Zendit vault' module for required action. 
As shown the user can choose to do one of the following: 



> Create a new key 

^ Delete a key from the zendit vault 

> Import a key from a local file into the zendit vault 

> Export a key to a local file 

^ Backup Locks and Keys to the web vault 

> Restore locks and keys to the web vault 

> Publish public lock 

> view the certificate associated with the key 

> Search for a public lock and import 

> Synchronize with web vault 
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5.12.1 Create a new key 

When the user chooses this option, the Zendit vault brings up a wizard. This wizard takes 
necessary input from the user. The wizard actions are explained in detail below. 

Key Creation Wizard 
Page 1: Introduction 

The first page in the wizard explains the need for a lock and key. 





You are about to generate a new lock and key. Use your new 
Lock and Key to Zendit (encrypt), DZend (decrypt), and digitally 
sign email documents and other digital data, 



By generating a lock and key for an email address, you are 
encryption enabling it and associating it with your Zendit user 
name. 



«zend l 




Page2: Name and email 



Name: The name with which the key will be associated. 



Email ID: The email address with which the key will be associated. 
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Zendit Lock and Key Generator 



M9 



Enter Your Email Address and select a Display Name 

Welcome to the Zendit Lock and Key Generator! Use your new 
Lock and Key to Zendit (encrypt), DZend (decrypt], and digitally sign 
email, documents and other digital data. 



What email address do you want to encryption-enable? 
sujathamanohar@hotmail. com 

Confirm your email address 
jsuiathamanohar@hotmaiI.com 

Type your name, as you want others to see it 
jsujathamanohaii 



Page3: Password for the private key and the settings for the key 
Password: The password that protects the user's private key. 



Confirm: The user re-enters his password here for confirmation. 



Zendit Lock and Key Generator 



"... -yy *»ty'f.s 



Enter and confirm Password 

Advanced Users 



If you want to change the default settings for Lock and 
Key generation, click on the advanced button 



Your password protects your Lock and Key from 
unauthorized use. Enter and confirm the password you 
will use to access your new Lock and Key for encryption, 
digital signing, and decryption. 



Password: 



Confirm: 



r 



« 



The user has an option to change the settings for the key if he goes through "Advanced" window. 
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If the user clicks on "Advanced" the following dialog is brought up where he can change the 
algorithm/expiry date/size of the key. 



i Key Properties Dialog 



Algorithm: 



T DSA-EJgamal 



Expires: 



& Lock and Key never expires 
§ j * Lock and Key expires on 



Size: 



T 768 bits 
1024 bits 
C 2048 bits 
C 4096 bits 

T Custom (768 -4096) bits 



Page4: Option to publish the certificate on the Zendit vault. 



Zendit Lock and Key Generator 



IE] 



Generating New Lock and Key 

Creating your unique digital lock and key. This procedure is 
computational intensive and requires considerable random 
number generation activity. It could take several minutes. 



PUBLIC LOCK 

Ym mn give your 
feci fel»ycm« 




PRIVATE key 



to- g&tr/pi (umm\ 



what otte^ will to ( „, ww 

I you* 1 pbtofaz lock 

Completed 
Publish this certificate on the Zendit vault 



If the user does not select this option, then this public lock will not be available for others to 
encrypt the mail for this email address. 
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PageS: Option to backup lock and key to Web vault 



Zendit Lock and Key Generator 




Publishing your Lock 



CHECK YOUR MAIL 

A confirmation mail has been emailed to you. Check your 
mail and click on the link to activate your new lock and key. 
This final step is a security requirement and prevents others 
from masquerading as you. 



W< Back-up Lock and Key to Web Vault 



mm* 



Page6: Backup Success 



Zendit Lock and Key Generator 



. -4l'> - y £t\ 'cfY 



Back-up Lock and Key 



FINISHED 



The new lock and key has been successfully Backed-up 
onto your Web Vault. You can download the lock and key 
at anytime from your Vault. 




Zendit Confidential 



Page 84 of 100 



Zendit Design Document 



5.1 2.2 Delete a key from the zendit vault 

Description 

When the user chooses a key from 'Vault' , a warning will be displayed to the user that if he 
deletes it, then he will not be able to read the text that was encrypted with this public key. 




If the user still wants to delete the key, the user needs to submit the password for his private key. 
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(Cii 



navr 

< J 




E01DD62F7D6D6675 : ^ 



'■ ^^ii^i^f*;^ ^ .. :v 




""^.^"^'Sk; 



If the user enters the correct password, he will be given an option whether to delete from the web 
vault also. 




If "No", then the key is deleted only from the Zendit vault. 




If 'Yes", the key is deleted from the Vault and also the Web Vault 
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5.12.3 Import a key from a local file into the zendit vault 



Description 

The user is prompted to select the key file to be imported. The selected file is then imported into 
the vault. 

If i xi 



Zendit - Import Lock and Key Wizard 



Enter Path and File Name 

Enter the file path containing the locks and/or keys you wish to 
import to your Vault. Supported extensions include: .zlk, .zky, .zfL 
and .asc files. 



Keys File: 



t:\surfboard\Exported\mykeyring.zfl 
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Zendit - Import Lock and Key Wizard 



Select Locks and Keys to Import 

The source fib you selected contains the following locks anchor 
keys. Make sure the boxes are checked next to the locks and 
keys you want to import and click next. 



Icons Sep, U ' i ■ • Key ID 1 




aditisuja <aditisuja@yahoo.com> 


831659EB61C 


m 


navinc@aditi.com <navinc@aditi.corm> 


8B68SBCBA1J 




, f 






5.1 2.4 Export a key to a local file 



Description 

The user selects the key(s) to be exported from the Zendit Vault window. The selected key is 
exported to the file. The user has an option whether to include the private keys also incase of a 
lock and key. Also, there is another option to save the file in the Ascii armored form. 



Zendit - Export Lock and Key Wizard 




Select public locks and/or private keys you want to 
export 

You can export one or more of the following Lock(s) and/or Key(s). 
If you are planning on giving this file to someone else, we strongly 
suggest you uncheck the box Include private keys'. 



EKa4 aditisuja < aditisuja@yahoa corm> 



881659EBf , 
fiRRSflRrRZJ 



p Include Private Key(s] 
E xport file: 



j E : \surf board\Exported\nnykeyring. 2f I 
r ASCII Armored Output 
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Zendit - Export Lock and Key Wizard 



mi 



List of Exported Locks and Keys 

The Lock(s) and/or Key(s) listed below have been successfully 
exported. 



fcdb Keys - " I ^ " ' z2 




§4 aditisuja <aditisuja@3jah00.com> 


881659EB61D 


fr navinc@aditi. com < navinc@aditi. com> 


8B688BCBA1S 








5.12.5 Backup a locks and keys to the web vault 

Description 

The user can select a lock and key in the vault and backup it in the web vault so that he can 
restore it back any time. 

If the lock and key already exists in the web vault for the same Login ID, he will be given an 
option to replace it. 



aditisu>" 
idifcisu' 1 




Lock and kej* a&eadjf feadked ^ Ifr^g^l^ 
personaLWeb Vault 0ts $m m&ti&; 

> overwrite the lode and ke? m 3>£ur Wsb 
Vault with the lock and key from yoi# Vaullh" 



YES 



m 
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5.12.6 Restore locks and keys to the web vault 



Description 

When the user selects "Restore" in the Zendit Vault, the following dialog will be brought up where 
can select the locks and keys to be restored to his Zendit vault. The dialog shows all the locks 
and the keys the user had backed up to the web vault. 



Zendit - Restore Lock and Key Wizard 



Select Lock and Key to Restore 

The following locks and keys were found in your Web Vault. 
Select the locks and keys you want to restore to your Vault. 
Note: This function imports copies only, it will not delete them from 
your Web Vault. 



0f§4 aditisuja <aditisuja@yahoo.com> 381 659EBI 

navinc@aditi.com <navinc@aditi.com> 88240FDB* 

sujatham@aditi.com <sujatham@aditL. E01DD62F * 

..- „ : : j 1 'J , > 1 IT 



i 




If all the locks and keys that are backed up to the web vault already exists in the zendit vault and 
if the user chooses "Restore", the following message is shown. 



Select Lock and Key to Restore 

The fo]lowin^^' ¥ - ^'V^^^jgwnd in your Web Vault. 



Sbfete them fr 




All selected locks and ke^s exid in & Vasifr 
and cannot be replaced 
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5.12.7 Publish Public Lock 



Description 



LWhen the user chooses a lock and key and selects "Publish Public Lock", the lock is published 
in the server so that messages can be encrypted for this email address by other Zendit users. If a 
lock doesnot exist already in the web vault, the following message will be displayed. A 
confirmation mail is sent to the email address. 




Locksuccessft 

now use your Leek te Zenti m$$$m^-: 
emails and files. If fhis is your tM UxkfB^ 
Key, you will receive a corfirmatson email l& ' 
activate. 



n * 



0K 



2 If a public lock already exists in the web vault for this email address (in tbIConfirmedCerts) and 
is associated for the same Login ID, then the user will be given an option to replace. If the user 
wish to replace, then the lock which he is trying to publish will be directly inserted into 
tbIConfirmedCerts after deleting the older one. There will not be a confirmation process in this 
case. 



y and tb' 
t clir 1 




Public lock found in vault for \h& mod 
address. Do you wish to replace? 



sstore to ^^^^^^^^^^^*^ ! 
j <Zendr^a^ii^?^^ 




3. If a public lock already exists for this email address in the web vault (either in 
tbIConfirmedCerts or tbIConfirmedTempKeys) but associated with different Login ID , the 
following message will be displayed to the user. 
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5.1 2.9 Search for a public lock and import 

Description 

The user can search for a public lock for a list of email addresses. If the public locks are found in 
the web vault for at least one of them, the user has an option to import them into his Zendit vault. 



Zendit - Search and import Public Locks Wizard 



Search for Public Locks 

Enter an email address to search the Zendit Public Lock Directory. 
If a lock is found you can automatically import it. If no lock is 
found, you can still Zendit and the system will generate an Interim 
Lock and Key! 

Email address: 

navinc@aditi. com,sikandarb@aditi. com H mahesh@aditi. com 
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Zendit - Search and Import Public Locks Wizard 



Search successful! Select Public Locks to Import 

Could not find public lock(s) for some email address(es) in the Web 
Vault. 

Please select the public lock(s) to import 







navinc@aditi.com <navinc@aditi.com> 


8B688BCBA1S 


m 


mahesh@aditi. com < mahesh@aditi. c. . . 


548E3D9BF24 




.1 : i f 





If »S 



Zendil - Search and Import Public Locks Wizard 





Import Successful! 

The Public Lock(s) listed below have been successfully imported. 







navinc@aditi. com < na vinc@aditi, com> 


imported 


6 


mahesh@aditi.com <mahesh@aditi.c... 


imported 




: 1 . 
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5.12.10 Synchronize with web vault 

If a public lock for an email address in the user's zendit vault is different from the one that exists 
in the zendit public lock directory, the user has an option to synchronize it so that his zendit vault 
gets updated. 

If the public locks for the email address in the zendit vault and in the zendit public lock directory 
are identical, then the following message is displayed. 




If the public locks are different, then the zendit vault brings up the following wizard to import the 
lock from the zendit public lock directory. 



Zendit - Synchronize With Web Vault 



Synchronize for current Locks 

The Public Locks listed below were found in the Zendit public lock 
directory. Select the Locks you want to import 



0j| navinc@aditi.com <navinc@aditi.com> SB 638B CBA1 \ 



« 
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5.13 Key Manager 

Description 

The basic functionality of this module can be explained in 2 steps. 

1. The Zendit Vault' is invoked that receives all the inputs given by user though the 'Key 
management user interface handler'. 

2. Specific functions on the 'Cryptographic Service Provider' are called and the appropriate 
values are passed. 

This module also decides the CSP to be used and bridges between the 'Zendit Vault 1 and the 
'CSP'. 

Listed below are the cases in which it takes the input from the Zendit Vault and sends it to CSP 
via specific function calls. 



Create a new keypair 


Name 
Email ID 
Key pair length 
Key pair size 
Date of expiry 
Pass phrase 


KeylD of newly 
generated keypair 


Delete a key /keypair from the key ring. 


Key ID 
Passphrase 


Success or Failure 
indication 


Import a key / keypair from a local file into 
the key ring. 


Local file name 

Key IDs of keys to be 

imported 


Success or Failure 
indication 


Export a key to a local file. 


Key ID 


Success or Failure 
indication 


Upload a key to the Zendit server 


Key ID 


Digital certificate 
(public lock) 


Download a key from the Zendit Server to 
the key ring 


Key ID along with the Digital 
certificate 


Success or Failure 
indication 
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View the certificate associated with the key 


Key ID 


Digital certificate 
details (such as name, 
email address, keylD, 
size and so on). 


Generate a revocation certificate for the 
specified key. 


Key ID 
Revoke key 
Revoke key size 


Not currently used 


Edit key passphrase 


Key ID 

Old Passphrase 
New Passphrase 


Success or Failure 
indication 


Change user id on the key 


Key ID 
Passphrase 
Old User ID 
New User ID 


Success or Failure 
indication 


Query the user's local key rings, a specified 
file or a specified memory block and 
provides information about a list of keys / 
keypairs available in the specified source. 


Key ring 
Key ring size 


List of structures, each 
containing details 
(such as name, email 
address, keylD, size 
and so on) for one 
digital certificate. 


Encrypt file 


Cleartext source file name 
Encrypted destination file 
name 

Array of Recipients) 
Number of recipients) 
Array of signers) 
Number of signer(s) 


Success or Failure 
indication 


Decrypt file 


Encrypted source file name 
Decrypted destination file 
name 

Pass phrase 


Flags indicating 
armored, encrypted 
and signed status of 
input content, signature 
details for each 
signature found 


List Recipients 


Encrypted content 


List of KeylDs of keys 
that can be used to 
decrypt the encrypted 
content. 
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6. Assumptions and dependencies 



> OpenLib will be used for encryption and decryption process. 

> Zendit will provide the hashing algorithm. 

> The SurfBoard would import the certificate only if email ID exists and the certificate is valid. 

> The SurfBoard will not support certificate revocation. 

> Hashing algorithm is performed both on email id and login id. 

> Admin pages will work on IE 4.0 and above. 

> The SurfBoard will work only with IE 4.01 and IE 5.01 on Win 98 and Win NT 4.0 
Workstation. 

> Maximum number of SQL Servers used can be extended to a fixed number of 100 servers. 

> When SQL Servers being used are increased, the Zendit system administrators are 
responsible for moving data across SQL Servers. 

> If the Zendit system is not able to send mails, it adds an entry into the error log. 

> The system does not support re-sending mails that bounced back. 

> Access mechanism for admin pages will be Windows NT challenge-response authentication. 

> User can upload more than one public lock but there can be only one public lock associated 
for an email ID existing on the server. 

> Reply to feedback will only be in text format. 

> The administrator maintains the correct templates of the various mail systems' web pages. 

> Once the user has logged in, the user information is taken from the LSM. 

> When the user logs out, the user will be logged out of all the SurfBoard instances and also 
from the zendit clients i.e outlook and Windows Explorer. 

> When the user encrypts (zends) an email, the mail is signed, compressed and encrypted. 
The encrypted text is then converted into an ASCII armor, which replaces the original 
message body in the email. 

> The OpenLib is viewed as a complete, reliable package and will be used as is. Hence this will 
not be tested. 

> 'SA - FileUp 1 object from Software Artisans will be used for file upload and download(will be 
implemented for later version) 

> Keys will stored be stored in the key ring as files (as supported by the OpenLib). 

> The Zendit system will not be signing the certificates. 

> The hardware setup and the required software should exist. 

> Support for displaying Advertisements will not be provided in Version 1 .0 of the system. 
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7. Error Handling and Messages 



This section explains the methodology that is to be followed for error handling and error 
messages for the Zendit web site and the SurfBoard. 

7.1 Web Site 



The standard for handling errors throughout the web site would be to indicate server-related 
errors as "Problem at the Server. Please try again or send a mail to support@zendit.com " 

The details of the server-related errors would be logged in the Event Log. This event log has to 
be manually monitored and addressed by one of the Zendit administrators. The user interface to 
view this log would be using the NT Event Viewer. 

Validation error messages that are thrown up to the user would be displayed on the same page 
itself. For easy maintenance all the messages would be contained in an include file. 

7.2 Surfboard 

Validations would be performed in every relevant function. These would be detailed in the low 
level design. 

Some of the specific exceptions identified during the low level design would be trapped using 
exception handlers, and user-friendly error messages would be displayed. 

The description of the error messages would be maintained in a Resource file. 
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1.0 Overview 

This document details the usage of different types of templates. It aims to provide the Zendlt 
administrator with the insight of how the template entries can be derived. 



2.0 Template Types 

There 3 types of templates: 

> Send Templates 

> Click Templates 

> Read Templates 

The Send and Click templates are used during the 'Zend' operation. The Read template is used 
during the 'DeZend' operation 

Note: All the templates are retrieved by using the ZendView Source utility and not by using the 
explorer's view source functionality. 



3.0 Zend Operation 

The process followed by the Surfboard while 'Zending 5 a mail is detailed in this section. The 
section under Send Templates helps the administrator with retrieving the 'Send' templates. The 
click templates are discussed with respect to sending the mail under the section 'Click' templates. 

3.1 Send Templates 

The send templates are used to identify the template to be used while trying to the zend a mail. 
These templates are also used for retrieving the values of the To', 'Cc', 'Bcc' and 'Body' fields 
from a compose page of a mail system. The activities performed by the surfboard while 'zending' 
the mail are detailed as follows. 

1 . Get the URL of the main document from the Address bar. 
For e.g., this URL would be 

http://lw4fd.law4. hotmail.msn.com/cgi-bin/compose?a=9681 39292230441 166934 
which is the URL for the compose page in Hotmail. 

2. Check for the mail system in the URL 

The surfboard obtains the list of templates available. Each template has a 'Mail system' field. 
For e.g., for the hotmail site, the mail system value would be represented as 'Hotmail'. 

3. The surfboard goes through the template list and checks for the existence of the 'Mail system' 
value in the domain part of the URL. 

For e.g., in the case of hotmail, the 'mail system' value 'hotmail' is checked for in the 'http:// 
lw4fd.law4.hotmail.msn.com/' string, (i.e., it tries to find the mail system string within the first 
7' excluding the Mp://' string. 
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4. If a template matches with the mail system, then the surfboard checks if the current page has 
frames or not and accordingly builds a internal list of matching templates from the available 
templates. The surfboard makes use of the 'Frame type 1 field in the templates to get the list of 
the frame based, non-frame based and iframe-based templates. 

5. The surfboard then looks at the 'URL Phrase' value to determine if the user is on a valid page 
from which a mail can be 'Zent'. 

For e.g., in the Hotmail system, the template that was built for 'Compose' page has the URL 
Phrase as Ycgi-bin/compose?\ This string is checked in the main URL that the Surfboard 
obtains. 

6. If the system is non-frame based, but the document has an iFrame imbedded in it, then the 
template is entered as an iFrame based template. The surfboard will look for the different 
fields from which the values for To', 'Cc', 'Bcc' etc is obtained. 

7. If the system is non-frame based and the document has no iFrames in it, then the template is 
entered as non-frame based template. The surfboard will look for the different fields from 
which the values for To 5 , 'Cc\ 'Bcc' etc can be obtained. 

8. If the system is frame-based, the corresponding templates are entered as frame based 
templates. The surfboard will go through each of the frames in the document and tries to 
match the 'Frame URL' field value in the document URL of each frame. Once a match is 
found, the Surfboard uses this template to retrieve the To\ 'Cc', 'Bcc 1 etc values. 

9. Once the matching template is found, the message in the 'Body' is encrypted with the public 
locks of all email addresses found in To', 'Cc' and 'Bcc' fields and placed back in the 'Body' 
text area. All these elements are retrieved using the 'Form name 1 entry. The To', 'Cc', l Bcc' 
and the 'Body' elements are part of the form specified in the 'Form name' entry. 

10. The Surfboard, then zends the encrypted mail by simulating the send functionality of the mail 
system using the click templates. 



3.2 Click Templates 

The auto-send of the encrypted mail is accomplished by using the click templates. A send 
template has an associated set of click templates. These click templates are used to determine 
the element in the document, which on clicking, simulates the mail system's send operation. 

A click template consists of the relational ID, element-type, attribute-name and attribute value 
fields. Each element has certain attributes and values. A set of click templates identifies an 
element that is clicked by surfboard to simulate the send option. Thus the element is described by 
element type, attribute name and attribute value combinations. The relational ID of a set of click 
templates is used to identify single element. A different set of click templates with a different 
relational ID denotes a different element. A send template can have different sets of click 
templates by which the Surfboard can simulate the send option. 

For example, if in a compose page of a mail system, the message can be sent by clicking the 
following elements, 
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<input type="submit" name="Send.x" value= M Send" id="Send" onclick="onSubmitCompose(1);"> 
And 

<img src = 7images/iSend.gif border = 0> 

The click templates associated with the send template will have the following entries. 



Relational ID Element Type Attribute Name Attribute Value 

1 INPUT type submit 

1 INPUT name Send.x 

1 INPUT value Send 

2 IMG src /images/iSend.gif 
2 IMG border 0 



This means send option can be simulated by clicking the element INPUT with attributes type, 
name and value which has values submit, Send.x and Send respectively OR by clicking the 
element IMG with the attributes src and border with values /images/iSend.gif and 0 respectively. 



4.0 DZend operation 

The ( Read ! template is made use of during the Dzend operation. The template is used to fetch the 
sender's email ID. This is to verify the signature of the sender in the encrypted message. The 
decryption process does not stop if the sender's email ID is not found. The process continues 
without the decrypted message being verified. The method by which the read templates are 
derived is detailed in the subsequent section. 

4.1 Read Templates 

The string between 'Header Start 1 and 'Header End' field values is retrieved. In the string 
retrieved, a sub-string between 'Sender Start' and 'Sender End' field values is obtained. This 
string would give the 'Sender's information. But to obtain the email ID from this string, the Token 
Begin' and Token End' field values are used. 

For e.g., in the Yahoo mail read page, the source contains the following. 



<INPUT type=submit vaiue=Move name=MOV> 

</FONT></TD></TR></FORM></TBODY></TABLE> 

<TABLE cellSpacing=0 cellPadding=0 width="100%"> 

<TBODY> 

<TR vAlign=top> 

<TD> 

<TABLE cellSpacing=0 cellPadding=1> 

<TBODY> 

<TR> 

<TD vAlign=top noWrap align-right><B>From:</B></TD> 

<TD>"center" <center@hotmail.com><SMALL>  | <B><A 
href=7ym/BlockSender?NBR=1&NE=center@hotmail.com&box=lnbox&Msgld=42 
01„3181411_22684_879_1762_0&inc=Scamp;num=&Search=&YY=75044&or 
der=down&sort=date&pos=0">Block address</A></B></SMALL></TD></TR> 
<TR> 
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<TD vAlign=top noWrap aIign=right><B>To:</B></TD> 

<TD><navcha@yahoo.com></TD></TR> 

<TR> 

<TD vAlign=top noWrap align=right><B>Subject:</B></TD> 

<TD></TD></TR> 

<TR> 

<TD vAlign=top noWrap align=right><B>Date:</B></TD> 

<TD>Sat, 2 Sep 2000 07:50:29 +0530</TD></TR></TBODY></TABLE></TD> 

<TD vAlign=top> 

<FORM 

action=http://address.mail.yahoo.com/yab/us?v=YM&cmode=1&Lang=us&a^ 
method=post> 

The Header Start the read template can be specified as <INPUT type=submit value=Move 
name=MOV> 

The Header End can be specified as <TD vAlign=top noWrap align=right><B>Date 

The string retrieved between these two values is 

</FONT></TD></TRx/FORM></TBODY></TABLE> 

<TABLE cellSpacing=0 cellPadding=0 width="100%"> 

<TBODY> 

<TR vAlign=top> 

<TD> 

<TABLE cellSpacing=0 cellPadding=1> 

<TBODY> 

<TR> 

<TD vAlign=top noWrap align=right><B>From:</B></TD> 

<TD>"center" <center@hotmail.com><SMALL>  | <B><A 
href=7ym/BlockSender?NBR=1&NE=center@hotmailxom&box=lnbox&Msgld==42 
01_3181411_22684_879_1762_0&inc=&num=&Search=&YY=75044&or 
der=down&sort=date&pos=0">Block address</A></B></SMALL></TD></TR> 
<TR> 

<TD vAlign=top noWrap align=right><B>To:</B></TD> 

<TD>M;navcha@yahoo.com><TDx/TR> 

<TR> 

<TD vAlign=top noWrap align=right><B>Subject:</B></TD> 

<TD></TD></TR> 

<TR> 

From this string, the surfboard fetches the string between the 'Sender Start' and 'Sender End' 
field values. The Sender Start can be specified as <TD vAlign=top noWrap align=right><B>From: 
The Sender End can be specified as <SMALL>  |  

The string retrieved between these two values is 
</B></TD><TD>"center" <center@hotmail.com> 

From this string, the surfboard fetches the string between the Token Begin' and Token End' field 
values. The Token Begin can be specified as < 
The Token End can be specified as > 

The string that is retrieved between these two values would give the sender's email ID 
(center@hotmail.com). 
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5.0 Template Blob 

The send, click and read templates are stored in separate tables. Changing any values of these 
templates does not reflect in the Surfboard. As the number of web based mail system that Zendlt 
support increases, we will end up having huge number of templates. For example, Yahoo mail 
system has around 10 templates. If we support 30 mail systems, the number of templates will 
around 300. Each template can be around 150 bytes, which means user has to download 45KB 
of data. Since very large template data is to be downloaded to the client, the template structure 
understandable by the Surfboard is generated, compressed, symmetrically encrypted and stored 
in a separate table. Clicking on the 'Create Blob' button in the admin templates page performs 
this activity. The application variable that stores the current template version gets updated in the 
respective system only after the template blob is created. The application variables have to be 
refreshed in the all other web servers for the changes to be reflected across the application. The 
new templates will be downloaded the next time user logs in to the system. When the surfboard 
makes a request for templates, the Zendlt webserver will send only the Template Blob and not 
the templates that are stored in a different table. 

Note: It is very important that when a template is added or modified, you should update the 
template blob so that the subsequent template request from the client (Surfboard) will get the new 
template. 

The 'Create Blob' functionality needs the SymmEncComp.dll component to be installed on the 
web servers. Those template changes made after creation of template blob will not be reflected in 
the Surfboard. 



6.0 Conclusion 

The process by which the different types of templates are derived and used by the Zend and 
DZend process has been explained. This is to help the Zendlt administrator to retrieve the 
templates and also to be a reference for templates usage. 
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DZend Flow in IE / outlook: 



User clicks on Dzend 
button. 




No 



^ Display the Login dialog box 



Notify the server to reset the new mail status. 



Yes 



Get the mail content 





Yes 


Enumerate the 




key blocks and 




> ► 


show them to 
the user. 


►< 




Import the 
certificates/keys 
chosen by the user 



No 




Display an error 
message that there 
is no encrypted block 
to decrypt 




Is it signed message or 
encrypted message? 



signed 


Verify the 


signature in the 


► 


- message. 



Put the signed 
block back in the 
Daqe 



Show the signature 
information. 



encrypted 



Is it public key 
encrypted? 



No 




Ask the 
passphrase to 
decrypt the 
symmetricaliy 
encrypted data. 



Show the above 
secret keys and ask 
the user to enter the 
passphrase for any 
of the keys. 



Decrypt the content 



Decrypt the content. 



1 


f 


Download the interim locks 


and keys(if any) on the 


server. 







Display an error message 
that the corresponding 
public key is not found in 
the vault and the content 
cannot be decrypted 




1 


r 


Put the decrypted 
content back on 
the page 




r 


Show the signature 
information, (if any) 



I 



Exit 



Exit 
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Publish Public Public Key Process Flow 

Case 0: Publish a normal public Public Key 

Case 1 : Replace the existing Public Key in the server 

Case 2: Publish a downloaded interim Public Key and key (automatically happens when the user 
downloads the interim Public Key and key from the server) 



© 




Insert the certificate 
into non-confirmed 
source 



Yes 



Directly confirm the public 
Public Key without sending 
the confirmation mail. 



Send a confirmation 
mail 



Inform the user that the 
Public Key has been 



Inform the user that a 
confirmaion mail has 
been sent 




Move existing certificate in the 
confirmed public Public Key 
<;nurr;p tn had r.prta 



insert the new public Public Key 
into confirmed source without 
sending the confirmation mail 



© 




the confirmed interim 
Key and key in the 



Directly insert uploaded certificate 
in the confirmed source without 
sending confirmation mail. 

I Z 

Delete the confirmed interim 
Public Key and key for this 
loginid- emaiiid combination. 



Zend process in IE 



User enters the Email address 
in "To", "cc" or "Bcc" fields in 
the compose page of any mail 
system, enters message and 
click on "Zendit " or sian 



Display error message 
"Unable to zend".And 
2§lso inform the user that 
' ie need to publish his 
«{ock and cofirm 



f an error 
message to the user to 
cpck if he is in a 
prefer supported page 





Request the user to 
enter atleast one email 
address in any of the 
three fields 



Display an error message 
that email address is 
invalid and also addresses 
should be separated by 
comma 





Inform the user that the 
identity of the recipients in 
the BCC field may not be 
concealed in the mail 
content. Click "Ok" to 
continue or "Cancel" to 
cancel 




1 



User clicks "OK" 



User clicks 
"Cancel" 



Yes 
I— < 



No 



Public locks for all the 
recipient email addresses 
exist in the vault 



1 


r 


Cancel the 
operation 




Yes 




Give an option for the user 
to select the emailids for 
which the public locks will 
be downloaded from the 
directory 



User unselects 
certain email 
addresses 



User clicks 
"OK" 




I 



Inform the user that 
those addresses 
unselected will be 
removed from the 
"ToYCc" or "Bcc" 
iist.ClickOKto continue 
or CANCEL 




User clicks 
"OK" 



User clicks 
"CANCEL" 



T 



Remove the unselected 
email addresses from 
the "To,"Cc" or "Bcc" list 



Ask the user 
again to select 
the emaii 
addresses 



Yes 




Download the public 
locks for the email 
addresses to the vault 




Give an option for the 
user to select the email 
addresses to be 
pnrrvntinn pnahipH 



User unselects 
certain email 
addresses 



User clicks 

"OK" 




1 



Inform the user that 
those addresses 
unselected will be 
removed from the 
"To'V'Cc" or "Bcc" 
list.ClickOKto continue 
or CANCEL 




User clicks 
"OK" 



User clicks 
"CANCEL" 



Remove the unselected 
email addresses from 
the To,"Cc" or "Bcc" list 



Ask the user 
again to select 
the email 
addresses 



Associate an interim lock and key 
for the selected email addresses 




Signs the message 
and put it back 




Encrypt the message for all the 
corresponding public locks and 
put it back in the mail content 
text box 




From the click templates of the 
corresponding mail system, 
identify the SEND button/image 
and simulate the click to Zend the 
mail . 



Associate a confirmation^ for the 
email addresses for which interim locks 
and keys were generated in this 
operation and send the confirmation 
mail( vaccine registration) 



t 

Set the NewMailStatus flag in the server 
for the LoginlD to which the mail is zent.( 
not applicable for the emailids for which 
interim lock and keys were generated in 
this operation) 



Zend Process in Outlook: 



Display error message 
"Unable to zend".And 
also inform the user that 
.feneed to publish his 
Ideft and cofirm 




Fetch the values of To,CC & Bcc 
from MAPI or the window 




Request the user to 
enter atleast one email 
address in any of the 
three fields 



Display an error message 
that email address is 
invalid and also addresses 
should be separated by 
comma 





Inform the user that the 
identity of the recipients in 
the BCC field may not be 
concealed in the mail 
content. Click "Ok" to 
continue or "Cancel" to 
cancel 




User clicks "OK" 



User clicks 
"Cancel" 





f 


Cancel the 
operation 




Give an option for the user 
to select the emailids for 
which the public locks will 
be downloaded from the 
directory 



User unselects 
certain email 
addresses 



User clicks 

"OK" 




Inform the user that 
those addresses 
unselected will be 
removed from the 
ToVCc" or "Bcc" 
list.Click OK to continue 
or CANCEL 



User clicks 
"OK" 



User clicks 
"CANCEL" 



I 



Remove the unselected 
email addresses from 
the To/'Cc" or "Bcc" list 



Ask the user 
again to select 
the email 
addresses 



1 



in 



Yes 




Download the public 
locks for the email 
addresses to the vault 




Give an option for the 
user to select the email 
addresses to be 
f^nnrvntinn Pnahlpd 



User unselects 
certain email 
addresses 



User clicks 
"OK" 




I 



Inform the user that 
those addresses 
unselected will be 
removed from the 
To" f "Cc" or "Bcc" 
(ist.Click OKto continue 
or CANCEL 




User clicks 
"OK" 



I 



User clicks 
"CANCEL" 



Remove the unselected 
email addresses from 
the To,"Cc" or "Bcc" list 



Ask the user 
again to select 
the email 
addresses 



Associate an interim lock and key 
for the selected email addresses 




■© 



Ask the user to select the 
signing key and enter the 
corresponding password 




Display error that 
the password is 
invalid and ask him 
to enter aaain 




Yes 



Simulate the Send operation in 
4 



Associate a confirmationiD for the 
email addresses for which interim locks 
and keys were generated in this 
operation and send the confirmation 
mail( vaccine registration) 



Set the NewMai I Status flag in the server 
for the LoginID to which the mail is zent.( 
not applicable for the emaiiids for which 
interim lock and keys were generated in 
this operation) 




^ 2.-Z- 



mm : \ 



CD 



u 



^ ;t: : & 



4J 
■H 
73 

£3 

OJ 

,£3 
4J 
■H 
!3 

& 
£3 
■H 

QJ 
4J 
01 
■H 
& 
QJ 
H 

o 

O 

£3 



Ph 
H 

K 

m 
w 

a 

o 

D! 

H 

B 

O 



o 

■— I 

QJ 
£1 

M 
S3 

■H 
-H 

QJ 

£3 
O 

J* 

u 

•H 
— i 

u 

QJ 

oi 

CO 
QJ 

01 
01 
QJ 
kJ 
73 
73 
OS 



03 
g 

QJ 



S 
U 
■H 

S3 
O 



o 



■H 



4J 
o 

X! 

< 

o 
o 

rH 

SJ 

OJ 

en 
qj 

■P 

P 

■H 

73 

S3 

QJ 



■H 

a 

w 

ft 
O 

X 
X 
& 





3 QJ 






) S3 






1 o 
< QJ 




X 


: g 




II 


o 




fZ 
H 


pi 






QJ P 




£ 


01 £3 




G 


03 3 




U 


U O 






^ u 


■H 


□ 


S3 U 




o 


•H CS 


g 






u 






■H 


QJ 


O 3 


<H 




> o 


£3 


m 




O 


QJ 


on 


U 


4-> 


p <h 




•P 


u o 


P 


■H 


QJ 


0 


73 


p a 


£3 


£3 


o "H 




QJ 


!hI ,£3 


O 


X 


a n 


73 


li 


M 




a 


P QJ 


QJ 


M 


OS £3 


m 


S3 


£ 13 


03 


•H 


P- o 


QJ 


CP 




■H 


o 


oi oi 


a 




ra g 




o. 


QJ *H 




a 


D 03 


p 


in 


0 «H 


■H 


«3 


SJ U 


-o 




a 


£3 


<H 


73 


QJ 


S3 


S3 S3 




0 


0 03 






■H 


J3 


M 


P 3 


P 


V 


03 O 


■H 


■H 


g > 












■H QJ 






4-1 P 


QJ 


g 


£3 03 


4-> 


O 


O £3 


01 




u o 


•H 




oi 


t» 


u 




QJ 


*H 


QJ 




73 
£3 


4-1 a 




o g 


P 


QJ 


•H 


o 


M 


P 

Ll 0 


£3 


& 


03 P 


T3 


& 


a 


■H 




on 


U 










•h a 






g 


o 


oi qj 


> 





TS 




M 




03 S3 




O O 












u a 








in u 




u 




QJ S3 




^3 QJ 








>— i 




O »H 












S3 




•H 




& 03 




O X! 




^ U 




T3 H 




S3 O 




03 4J 




03 




73 H 




03 QJ 




QJ £3 




£1 QJ 




03 & 




O QJ 




& JJ 




03 




^ D 




M *H 




£3 4-1 




•H -H 




-1 4-1 






p; 


QJ QJ 




> U 




o 






o 


ro qj 






PQ 


QJ 




^3 73 




4J £3 



T3 

in qj 



D QJ 



03 in 
m 

W QJ 
u Jj 
O 73 
H 73 
03 



O -H 



£3 g 

QJ QJ QJ 

" a 

o 01 



g 
o 
u 

4-1 



,£3 

O 



■H 

^3 



QJ 

QJ 01 £1 





QJ 




U 




O 




g 




QJ 




£3 




O 




QJ 




> 




•H 




QJ 




U - 




QJ QJ 




U 




03 




H U 




— t -H 




■H 4-1 




& H 












O QJ 




> D 




QJ U 


w 






03 O 


H 


U > 




■H 


*! 


H S 




■H U 


U 






^ m 


M 


QJ £3 




U 0 




o 






H 


3 0 




o u 


H 








P5 


73 £3 




QJ -H 


w 






03 


U 


U 03 




QJ 




£3 3 




QJ O 




tn > 


PS 






QJ tn 


M 


> £3 




03 -H 




A > 




■H 




3 til 




o 


O 






•H 




QJ 73 



QJ 
•P 
Q3 
U 
■H 
4-1 

-H 
*J 

!h( 
0J 
U 

u 

o 
> 

4H 

O 

1> 
JJ 
•H 

Sj 

til 
QJ 

4J 

£3 

•H 

QJ 

r£3 

QJ 
U 

01 
£3 
QJ 

O 

4-5 

01 

a 

QJ 

4J 

01 

> 
u 

03 
01 
01 
OJ 

o 

QJ 
£3 

QJ 
U 
03 

QJ 
01 



c 

c 



o . 
CO 

III 

IS , 



M 
£3 



g 
O 

O 73 

a £3 
a qj 

■rt O 

73 aJ 



qj 
& 
o 

01 
•H 



3 
> 



; C 



: T3 
■ C 
: H 

' M 
: Cl 



| c 



I2t 




( K5" 



ID 
C 

c 



in if 



CD 



CU 
C 

o 



00 
T3 

< 



c 

E. 

■6 



CO 
0} 

< 



@ 

CO 
CD 



01 

CD 

4 



8 

o 



g 

Q 



CO 
3 

d 

10 
CD 



CO 



o 

b 



a*. 

IS 
CO 

"a 
m 

& 



f 

&5 



o 
fx, 

CD 

H 

o 

L 

CD 



o 

O 

CD 
to 



V 

















OJ 






CO 


w 




J3 








pq 


w 








iH 




«cj 




H 


in 


O 




m 




M 


w 








> 


Q 


ft 








ft 




ft 




w 




Ei 




M 




[SI 








w 




■P 


pq 


o 


cj 




•t-i 


aj 




OQ 






M 






OJ 


o 




> 


o 



l» M 
S3 

H 
o 



M IT, 

O 73 

> M 

l> > 

ft oo 

S« 

N CD 

DSI q 
Oi 

■i-i Oj 



H PQ 

H K 

LO 

U >-« 

■ ft W 

aj tj 1 p, 

<h £ cu in 

CD t3 J3 

fl n M 

[3 



PQ 



K 

13 

S3 

W 

W 

H 

JQ 

CJ 

w 

PQ 
& 
i— i 
4-! 
O 
U 

o 

& 

C* 



i3 

I — I 

13 

K 

ft 



CO 

ccr 
& 

r- 

ft 

w 

Q 



N CD 
- U 
S4 13 ^ 

.Q W 

> g ss 
to '-h r! 

PQ d? u 

H K LO 
«5 U W 

K u i-i 
in -=<J 

ft ^ 

> cu 

ft" u 

t3 

o 

E3 

O 
H 
O 

t> I- ID 

ft -I-, tr 1 
w en K 

^ !=> „ 
& li-j 

n cb 

J CO 

ft HH 

& 1 o 



ess K 
0"J ' — I 

W ID 



w ^ 

O EJ 

O OJ 

•r-i u 

a 

u r- 
cu 



> 

M 

K 
J 
a > 
i — i r- 
l> K 
t-J 

'■^ + 

r- & 

-H t-D 
t3 1—1 

JxJ CSI 

^ >-D 

AC! fl 
'■jD CU 

O-i K 

ft TS 

^ XJ 

O P=l 
LO 

CTi oj 



ft 

pq 



co 

•i-i i 

Is 

■ ' n 
o 

ft" 



ft 

pq 

a 
o 

bJ 
Q 
■C3 
T 

!^ 

?J 
O 



a 
H 

b § 

CO U 

s d 

OJ 73 

•h a 

X] i_q 
73 
X! u 
c-J ft 

(3 

_ tS 1 ft . . 
t + CO -i-i u 

X pq H u esi 

O co cn in 

C(J oj tyi O 
o 



r=l i OJ 
•H > 

a 

tv CO 
' — I u 

cl 
in 
t) 

W 
U 
«5 

M 

r- 
S 



■H 3 



a 
i — i 
cu 

OJ 
J3 



><j 

IS] J:-. 
i~i Em 

a W 

O H 



tH '-JZI 

u ^ 

C-] H 

m if 

pq co 

ft ft 

> o 



ft- 

ft 
K K 

•H |> 

H r- 
'■H rH 



> 

4-J II 

^ II 

^3 i3 

U ^ 

pq M 
> 



O 4H 

CU + 

73 4-i 

!=" 73 



in 
in 



ft 
ft 

w 



CJ * 



□ 



IZ1 



T3 
CD 



9 



g: 

XJ 

cn 

BO 



CD 



a 



o .■ ail 

S M 



cu , 



•: 0 
' O 

IS 



( ^fc 




/ Hit 



a h 



at 
ot * 
o 



r 4iJ 




CO 



£ il u :i 



1111,., 



CD 

(J 
O 

CO 



TS 
< 
> 



5 « 

— : a> 

— u. 

® £ 
5 e> 

Si 

V rn 

Z CD 

S5 1= 

to 4; 

= -o 

a) c 

x a- 

: x 



O 

o 
o 

rsj 
un 

ro j 

ro I 
rM 

as 5 
.E r-i 

8- 



"5 S2 



M 

V 



I CM 

I CO H 

! I J3 

! I ~ pq 
w 

CO O 
EQ - J-t 

W -H 

K > ft 

a, o >. 

1 o 



f= -2, 



I** 

H 

□ 
Si 



o ts 
> 

r- 
P< 

ft . . 
w co 

M ft 

•n 03 

& 
S3 
W 

■rl 
■Q 

u 
w 
pq 



4H 

O 
U 

O 



03 
U 

—I 

pq 



h a 

w M 
O H 
ft h 

S LTl "JD 

■h p, x: 

tr ft i> 

CO & £ 

ft CO PO 

H H CO 

U £} CJ 

> s 

CO 4-i 
pq O 
m K 

u H 
K CJ 
CO 

PS 



XI 

TS 
CJ 
LO 



> O 

PS O 

> ft 



4J 

'■D H 

pq i-i 

O ft 

o 
ft 



ft rrj 

CO 



r- PS 

J IS 

DJ rH 

13 O 

T3 & 



H W ^ 



a ft 



en 

TS 



W CO 



as m 

tr 

-- + 



r- 
PS 

ft 



^ J ITl 



& o 

co u 
> o 
S 3 

OJ TS 

ft 

ts 

X! cj 

m as 

' ' 03 
CO -r-| 
CO C?r 



> 
fH 

W 

- J 
ft > 

h r- 
> s 



r- 

-M I'D 
& 1-4 

tH TS 

& ^ 

as ft 

'■O OJ 

CU TS 

^ ^ 

0 CP 

P LO 

ft ^ 

01 CM 
O M 

CM 
-I W 
■H > 
ft rH 

M H 

co 

CJ 



Pi 

E- 



+ 

LO 

. . 
o a 
co <r 
•n <h 
--- & 

rjj 

M CM 

O *h 

pi a 

K ft 
CO TS 
O 1* 
ft 



co m 



o 
S 



P* - - „ 
O DJ CO 

w ^ 



3 

? + 

W O 



PS 

- & 
CM 

•r-i [th 

ft K 

O -H 

>• > 



■n ^ 



cj ^ 

[■] bJ 

C« OJ 

W X 

PQ CO 
Pi 

JZi ID 



CO 0=1 M 



XI 

c 

0J 



O CJ 



^ Pi 

■H Ph 



> 

□ m 

QJ + 



w 

CO 
CO 

w 

Ph 
Ph 

ft 

a 

w 

1 
I 



{ So 




OS 



















r J 






O 






L> 






E- 


















M 






X 












!> 






►4 












> 






5 






o 












il 












M 






'4-1 










PS 


0 


o 


!=. 


r J 




O 




■— 1 


>< 


£ 


4J H 




0 


£ Cfl 


4-1 


D 


as g 


0 


& oj 




rH 




a 


•H 


3 PS 


•H 


03 


□ i=> 


£| 


£ 


> o 


on 








O 


4-1 


oj 




h rij 






-H 


[3 


CO 




Q 


Q 


>— l CO 




■H 


•H -H 


OJ 


i-J 


03 £ 


& 


OJ 


S u 




4_J 


cu 


o 


TO 


S 


4-1 


0J 


«— 1 u 




4J 


cd -h 


Q 


4_) 


■H <H 


jj 


■H 


4J El 






G □ 


CO 




U U 


CU 


ill 




■H 


X 


•H □ 




II 














□ w 


OJ 




U £ 




•H 


■H 


o 


03 




OJ 


P 




£= 


W 


CO tn 


o 


O' 




DQ 


p, 


T3 -H 




Ef] 
03 


QJ £ 


OJ 


tn o 


CO 




OJ rH 


03 


0J 








•H □ 




0 








■H 


■H 


,—1 


M OJ 




0J 


p, rj 


■-< 
r-" 




U 


0 


E> 


03 


> 


0J 


S3 




J* 


3 O 




a 


O 




s 




u 


0J 


u 


OJ 




4J -H 


o 




£ ■H 

CU U 


Q 
U 


o 


TO 


a 


u 


CU 






> to 




4J 


-i 03 


0 


•H 


P cu 


■H 


-a 




4J - 


cl 


cu a 


03 on 


OJ 


u 


g TO 


w 


cu ^ 


U 0J 






■H U 




■H 


4-1 13 










h jj m 


O 03 






U 




03 > cu 






s u u 


DQ -H 


a 



3 
□ 



□ 

U -H 

o *c 
a £ 
a qj 

in m 

u u 
■h o 
ts al 



OJ 

& 
o 
ex 

to 

•H 

> 
u 

03 



jr. 

3 



O 
D 

«- - 
C ' 
O 

Cl * 

net , 



X3 

c 

05 



e & 

<D i:: 



if" 



;Blff 



iiii 



y>--:J::::-i^v::'i 



31 

^ ; 
-p 

j=i :j; 

S; 

CM & 
LD : : 

<+• If! 

si 

05 

:; 

Ul :;: 

JQ ifi 

si 



Q. j; 

if 



■ ? ::: :o?h: 





1_ 




o 




=3 




o 




O 


o 




CD 


>^ 




_0J 


_C 




-1— • 
03 






o 

CD 


rrn 


E 


CO 


O 




CO 


_C0 


i_ 




CO 


7D 
i_ 




CD 


CO 


03 


o 




S3 


O 






<§ 






:=» 


CD 


i_ 


05 


CO 




o 


• 


-+— > 


Will 


£Z 
CD 
O 


All i 


ipue; 


-4— ' 

CP 




-i— ■ 


M 



:£z CO 
™ cc 



CJ 



CD 



ir; I — 



CD 



CD O 
CO E 

CD 03 

•+= £ 
re : =- 

to -° 
_ >^ 
~ u 
-a cc 
c > 

CD 'ZZ 



CD 

m ^0 
£ O CD 



CD 

o 



; CO 



8 5 



"3 

O 



CLi 



■a 

CD 03 
CD 



CO 
03 

CD "CJ 

c 

CD 



CD 

03 c C 

- ■— OJ 

1 w ^ ■ 

^ — CO 

° to to o 



.t=: 05 



CD CD 

5 * 

lE ^ 

^ O 

Q CO 

CD § 

E 

CD CJ 

? g 



3 

o 



SZ £L CO 



CO K 

CD * 

o — 

Q_ 03 

£ £ 

sr o_ 

CO >-, 

iT> O 

CO CD 

ri -o 



CO 
£Z 
J= o 
CO 

cS 

q CD CD 

CO CO 
CD J^T CD 
>-■ 

£Z CD .E 
CD ^ ^ 

IS" 

CJ 



CO 



-a 

CD CD 



CD 

•4— 

o 

CD 



-T3 _ 



a cd 



o 

CO co 
O 



O O CD .2 

.—- U— 



_CD 

J3 
CO 

CO 

.2 

"a. 

>^ 
i— 

o 

c 

CD 
CD 



CO 
CO 
CD 



CO 
CO 

£ 

s 

c 

CD 

M 



o 
to 



CD CO 

^ CD 

E ^ 

t CD 

aj _q 

° o 



i_ CO 

CD CD 

-a s= 



CO 



CO 



(52- 



CO 
j— 

aj 
o_ 

oj 

-±- -5 



CO e"' 



■~ 05 

CD SZ 

M 5: 

OJ CO 

-S= CD 

-•— 1 -4— • 

05 



03 t— 
£ CD 

o M 
= c 

OJ 

CO CO 



CO ~D 

5 s 



"O _ 

CO CD 

o cr 

"£ ^ 
o 

~0 — 

_ 03 

o £ 

>-. CO 

^ £ 

OJ Q 

r> ZD 

>■ CO 



05 

-a S 

ci * 

' 

-O Q_ CD 

2 CD -C 

c: = 

CO O 03 

03 O CJ 



° J^ 

.t^ CO 

c o 

OJ -tz 



CD CD 
SZ 

— CO 
s= 

o = 
CD 



CD 



pj ^ 

^ CO 
CO o 



qj to 

^ co co 

O 05 CJ 

>^ _0J o 

it a a 



Hi 

« 
c 

I 

CD 



E 

(5 



3 ; 



0> - 
O . 
CJ 
3 

c 
o 

■u ' 

05 

Ci :: 

a . 



"O 



i 





I 




I 75 



:;::: 



j-t^ ;i tj- ;;;;; 



A 
A 
A 
A 
A 

o 

H 
H 

Pi 

H 

o 

U 
H 

M 

Q 

w 
[-■] 

V 
V 
V 



o 
ai 

J* 

£3 
■H 



Hi 
X! 
P 

S3 

O 
•H 



OJ 
OQ 
115 
OJ 
•— I 

a 
n 

DQ 

aj 
u 

T3 
75 
05 



P 
•H 

TJ 
£3 

xl 

P 



£3 

•H 
U 
QJ 
P 
OQ 
■H 
& 
OJ 
U 

U 

Q 

m 
□ 

!> 

4^ 
Pi 



•H 

05 

A g 
aj 

to 

•H 
Xl 

in 0 

PS 4-1 

□ 

a 

S3 



Pi 
■H 

XJ 

to 

k! 
iLI 
S3 
13 
O 

U 

□ 



S 

■H 

4-1 
S3 
O 



PS 



o 



M 
(LI 
P 
DQ 
OJ 
P 
P 
■H 
T3 
S3 
aj 

1! 

Q 
M 
£3 
•H 
01 
O 

a 

DQ 

m 
S3 
□ 
u 

M 

u 

•H 

EL 
s 

o 

D 

4-'' 
■rf 

c 

(LI 
H 

& 

& 



OJ 
S3 
□ 

g 
0 
DQ 

OJ 

DQ 
05 
O 

S3 

•H 

O 
> 

P 

u 

(LI 
P 
O 
U 

a 

p 

oc 

X! 

P 



S3 
o 

■H 

AJ 

DC 

g 

M 
■H 

m 
S3 
o 
u 



P 

£3 

o 
o 
o 
(d 

u 

o 
> 

m 
o 

a 

■H 

X! 
DQ 
U 
H 
S3 
!3 
D 



DQ n 

01 S 

OJ *H 

U 05 

O —l 

U U 

a 

75 



OJ 
P 

CO 

o 
oi 
u 
m 
4-i a 
o g 

■H 



05 



p 

Jul 

05 

a 

DQ 
■H 



o 

4J 

DQ 
P 

a 



DQ OJ 





















15 




O 










i-i 




U 










05 


£3 


4-1 










O 


O 












-Q 


■H 


<— 1 










•w 




•H 










u 


a 


05 












> 


s 




QJ 






DQ 


u 


GJ 




at 






OJ 


S3 


OJ 




u 






X! 


11 


u 




■H 






P 


<— 1 


o 

g 




-i H= 

11. 






O 


<H 








P 




P 


■H 


OJ 




M 


■H 




S3 


3 


on 




aj 
u 


g 




■H 










u 




& 


05 


aj 






•H 




O 


X! 


> 






m 




>H 


4J 


■H 




o 


fl 








OJ 






o 




T5 


U 


u 






u 




S3 


O 


OJ 


aj 


m 






05 


0 






o 


P 






05 




05 




□ 




T5 


U 


•H 


u 




S3 




05 


(LI 


>— 1 


•H 








OJ 


S3 


•H 


4-1 


■H 


□ 




Xl 


aj 




•H 




TS 




05 


& 




0 

u 




HJ 




O 


(LI 


o 


OJ 


0 


m 






■P 


> 


u 


S3 


05 






05 






■H 


aj 






U 


OJ 


u 










■H 


W 4J 




11 


a 




S3 


<H 


05 


0 


£3 






•H 


•H 


H U 




0 




Q 


■H 




•H 






P 






M 


4-1 


g 


OJ 


•H 


PS 


OJ 


OJ 


•H 


M 


S-i 


T5 




> 


u 




■H 




S3 




o 






4-1 


DQ 


0J 






> 


M OJ 


S3 




r-j 


O 


■s 


OJ 


U 


CO 


aj 


XJ 


PQ 


OJ 








o 






X! 






O 


u 


■H 




4J 


S3 ■ 


□ 


0 





(Li 

IQ 
■H 
& 
(LI 
U 

4J 
O 
£3 



3 

O 



PS S3 
O 

D 

T5 

tn aj 
u 

o -h 



DQ 
DQ 
QJ 
U 

•d 

05 



E- > 



PS 



O 



OJ 

5 

XI 

o 



05 

S3 g 

aj aj 
a 

o DQ 

■H 

-I X! 

■H 

& aj 



j^ 
S3 



o 



aj tn 
> S3 



S 

O 



□ 



J (LI 01 



U QJ TS 



DQ 

a 

(LI 
P 

> 

05 
DQ 
DQ 
0J 
U 
OJ 



OJ 

U 
05 

0J 

DQ 



*: 3 

•i 5* 



: C 



:-0 

IS 



o 

D 

P P 
U "H 
O T5 

a s3 
a aj 
^ w 



□ 

!> 
P 

M "H 
S3 T5 




c 

3 



1 — 1 


T 1 


1 — 1 


o 


o 


o 


o 


o 


o 


CM 


CXI 


CXI 






















P4 






Ill 



CO 




s 

a 
CO 

o 

JO 

m 



0) 

> 

C/J 
A 
£ 

5 » 

■— L_ 

S < 

jz 9 

® £ 



0) o 

1 « 

if 

V 

^ u 

= ^ 

X OJ 



is 



a 
o 

§ S 

■£ CD 



w 

o 

to 
to 
. w 



V 

I 

CM 



i a O 

a 

i S m 



•JSP 
Q O £ 

I -H (LI 
1 W £ 




Z3 ' 



o 

3 

o ■ 

XJ 
CD , 
Oi 
Ol 

_o 



'8 



11 



■ w 

•5 



CD 
C 




o 

P 

H 
P -H 

£3 OS 

& OJ 

3 Pi 
O i=" 
!> O 
!>■ 

4-i 

m m 

■H 



■H 

P 

S 
■H 

d 

o 



(U u 



■H 

o 



75 -I 

fid & 



OJ 

& 

QJ 



■H o 

> m 

■H 

u aj 

P 



03 



3 o 

□ 

u 

p -H 

aj u 
tn 

cu 

> on 
-h an 
p cu 

qj a 
u 

QJ ^ 
U P 
•H 

H p 0} 

■Ham 
CO > aj 
S u u 



(3 
O 
U 

a 
S 

QJ 
P 

t3 
W 

& 
!'■■] 

in 
o 

K 





K 


Mh 


p> 


£) 


'"J 


o 


if 


>" 






hH 


4-1 


4-1 


Q 


r 1 
t-t 




O 


o 

i-k 




.,_( 




,b 






o 




D 


QJ 




fH 
»H 




J3 




i— i 
u 


CD 






QJ 


p 




O 


£_l 


Ah 


O 


< 


4-1 


T-i 






_ 
u 


1— f 


p 


u 

QJ 


tn 


P 


QJ 


ff"J 


■H 


QJ 


H 


P 


P 


P 




■H 


QJ 


-a 


C3 




□ 


u 


CU 


w 


a 


ii 


o 


Q 


on 


H 




«H 


QJ 


■H 


Oj 


CCS 


03 


s 




w 




o 




a 


■H 


on 




03 




o 


p 
















4H 


□ 


QJ 


aj 




P 




o 


S 


M 


o 


a 


u 




p 


o 




■H 




4J . 




oc en 


QJ 


S tn 


tv] 


U QJ 




■H U 


& 


4-1 -C 




a -a 




□ 03 




u 








CO -H 


a 



c 

QJ 
C 



"to . 
w 
qj 
a 
o 



o 



QJ 



Q 
U 

P P 

□ -a 
a a 
^ a cu 

3 3 M 

> p 

p u 

X -h o 

a -o aj 



qj 

13 
D 

■H 

u 
03 




( <k6 




I Si— 



United States Patent & Trademark Office 

Office of Initial Patent Examination - Scanning Division 




Application deficiencies found during scanning: 



□ Page(s)_ 
for scanning. 



of 



(Document title) 



were not present 



□ Page(s) 

for scanning. 



of 



(Document title) 



were not present 



^ Scanned copy is best available. J^L^W-i^- 



